Newsgroup: it.comp.programmare.win32
Titolo: HANDLE non validi

Una domanda apparentemente sciocca, ma sto cercando di capire: se io 
distruggo un HANDLE, per esempio un HPEN, HBRUSH, etc... è lapalissiano 
che l'HANDLE poi non è più valido.
Ma se io sadicamente lo riutilizzo, windows riesce a capire che non è 
più valido e gestisce l'errore, oppure va miseramente il crash 
l'applicazione?
Mi rendo conto che la domanda sembra stupida, ma in realtà io mi trovo 
nella situazione di implementare delle funzioni di libreria dinamica che 
si comportano in modo analogo (cioè, creo un HSESSION che nelle mie 
funzioni è un puntatore ad una classe C++) e volevo capire se c'era un 
modo per "controllare" errori di chiamata del genere, possibilmente 
evitando che il programma vada in crash anche durante il test.
Pensate sia possibile? In C/C++.

 l'applicazione?
Buona la seconda.
-- 
ciao, hal

> Buona la seconda.
non diciamo cazzate per cortesia...
[CODE]
#include <stdlib.h>
#include <stdio.h>
#include <iostream>
#include <windows.h>
using namespace std;
int main() {
	HANDLE hFile = CreateFile(TEXT("C:\\pippo.txt"), GENERIC_READ,
FILE_SHARE_READ, NULL, OPEN_ALWAYS, 0, NULL);
	if (hFile && (INVALID_HANDLE_VALUE != hFile)) {
		BY_HANDLE_FILE_INFORMATION bhfi;
		CloseHandle(hFile);
		try {
			if (GetFileInformationByHandle(hFile, &bhfi)) {
				cout << "oddio... O_o'\n";
			}
			else {
				cout << "hal1961 e' un incompetente\n";
			}
		}
		catch (...) {
			cout << "hal1961 ha ragione e me ne scuso\n";
		}
	}
	system("PAUSE");
	return 0;
}
[/CODE]
provalo e poi fammi sapere ;)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 non diciamo cazzate per cortesia...
fermo li', tu fai un esempio con un file, ma
l'OP ha scritto:
| se io distruggo un HANDLE, per esempio un HPEN, HBRUSH, etc...
| č lapalissiano che l'HANDLE poi non č piů valido.
| Ma se io sadicamente lo riutilizzo, windows riesce a capire
| che
| non č piů valido e gestisce l'errore, oppure va miseramente
| il crash l'applicazione?
Sulla PSDK a proposito di DeleteObject e` scritto:
<QUOTE>
The DeleteObject function deletes a logical pen, brush, font
bitmap, region, or palette, freeing all system resources
associated with the object. After the object is deleted, the
specified handle is no longer valid.
</QUOTE>
In base a cosa si puo`/deve incoraggiare ad usare un handle
dopo che e` stato dato in pasto a DeleteObject?
-- 
ciao, hal

 dopo che e` stato dato in pasto a DeleteObject?
nulla ovviamente.
PS: se vuoi posso sviluppare un programma analogo usando un HPEN o un
HBRUSH; credo che l'output non cambierà, anche se potrei sbagliarmi finché
non verifico.


 non verifico.
Te lo dico io: l'applicazione continua a stare in piedi.
Non so pero` alla lunga quali effetti collaterali si possano
verificare, visto che e` un comportamento fuori specifiche.
-- 
ciao, hal

 verificare, visto che e` un comportamento fuori specifiche.
Aggiungo questo estratto da
Introducing the Bugslayer:
Annihilating Bugs in an Application Near You
di John Robbins
(che e` uno di debug se ne intende ;-)
http://www.microsoft.com/msj/1097/bugslayer.aspx
In fondo alla pagina, nel paragrafo "Slay Those Bugs!"
scrive:
<QUOTE>
Tip 2: Always check CloseHandle's return value.
Even though there is not much you can do when CloseHandle
returns FALSE, it is generally indicative of a serious problem.
Since Win32 will reuse handle values, it is quite easy to
accidentally close an open handle being used elsewhere in your
code, causing weird random bugs.
When you call CloseHandle on a handle that has already been closed,
it can sometimes cause random crashes that are impossible to track
down. Place all your calls to CloseHandle in VERIFY macros so that
you stand a fighting chance of finding those bugs in _DEBUG builds.
(Thanks to Jim Austin.)
</QUOTE>
Mi sono divertito a chiamare la CloseHandle del tuo esempio
per tre volte ed anche a scrivere nel file con WriteFile.
Ho anche provato ad ottenere un handle da CreateFont, darlo
a DeleteObject ed usare lo stesso handle per scrivere sulla
finestra. Ed ha funzionato lo stesso.
Pero` tanto il tuo esempio come il mio codicino di prova per
gli oggetti grafici erano piccoli programmi usati per qualche
secondo e la probabilita` che l'handle venga riciclata
dal sistema operativo e` tendente a zero.
Immaginiamo invece un programma complesso utilizzato su
una macchina dove gira magari un altro po` di applicazioni.
E stando a quanto dice chi ne sa sicuramente piu` di me,
non e` con un programma di una ventina di righe che ci si
puo` tranquillizzare su un uso "disinvolto" degli handles.
-- 
ciao, hal

 puo` tranquillizzare su un uso "disinvolto" degli handles.
ancora un volta, metto bene in chiaro che io NON propagando l'"uso
disinvolto" di cui sopra degli handle Win32; è necessariamente error-prone.


 tale da poterlo riprodurre in maniera analoga nel suo software.
Il punto è molto semplice:
Implemento un HSESSION che dentro le mie funzioni di libreria è un 
puntatore ad una classe C++.
Ora, se richiamo una mia CloseSession distruggo l'oggetto. Il puntatore 
da quel momento non è più valido e qualsiasi altra chiamata di funzione 
con quell'handle non andrebbe fatta (già... ma se la fanno?).
Stavo valutando se era possibile (in qualche modo) verificare se quel 
puntatore punta ad un oggetto valido del tipo giusto. Pensavo di farlo, 
ma nel caso di un puntatore non valido non ho trovato un modo per fare 
un test che non mandasse in crash il programma.
Per questo mi chiedevo qual'era un comportamento "standard" di windows.

 ha scritto nel messaggio 
news:393dspF...@individual.net...

prova a vedere se IsBadReadPtr() può esserti utile