Newsgroup: it.comp.programmare.win32
Titolo: [Forse OT] C/C++ - Scrittura in zone di mem non allocata

Chiedo a voi che forse ne sapete + di me.
Vorrei fare in modo di evitare, nella programmazione in C, VC,
di andare a sporcare zone di menoria che non ho allocato o
che non devo.
Mi è capitato a volte: a causa di un offset sbagliato di
qualche variabile o a causa di puntatori sballati.
Ho pensato alla costruzione di funzioni o classi apposite, ma
dovrebbero essere fatte per tutto: dalle stringhe alle liste e
ad altri tipi di allocazioni in memoria.
Possibile che in C non ci sia il modo di farsi dare un errore a
run time se il programma va a scrivere in zone di menoria non
precedentemente allocate dallo stesso?
Sapete darmi consigli?
Grazie ciao.

Dimenticato:
Uso Win98 SE e Microsoft VC++ 6.0.

 precedentemente allocate dallo stesso?
Il bello del C e' che ti permette praticamente tutto. E' come un
linguaggio assembler per un microprocessore di alto livello.
Quello che vuoi fare tu e' possibile in C++ con delle classi
apposite dette smart-pointer. Non risolvono tutto, ma aiutano
a dellocare sempre la memoria e, in alcuni casi, ad evitare o
intercettare il dereference di puntatori non validi.
Ciao. Federico.

Ciao, Diego!
Il giorno 07/11/2003 alle ore 08:51 hai scritto:
 D> Possibile che in C non ci sia il modo di farsi dare un errore a
 D> run time se il programma va a scrivere in zone di menoria non
 D> precedentemente allocate dallo stesso?
Di standard non c'e' niente che io sappia, pero' ci sono dei programmi che
monitorizzano il tuo programma e rilevano ogni accesso "strano" alla memoria
e alle risorse del sistema. Conoscevo uno che usava BoundsChecker (purtroppo
non ricordo il nome del produttore e ho visto con Google che ce ne sono
parecchi...) e gli ritornava oltre agli errori nell'uso della memoria e dei
puntatori anche errori nel passaggio dei parametri per le API standard e
tante altre cosine. La prima volta che si eseguiva su un programma c'era da
svenire per la quantita' di warning che trovava.
Bye

 che non devo.
Usa IsBadWritePtr e __try/__except + EXCEPTION_ACCESS_VIOLATION.
Ciao,
Marco Era
http://www.marcoera.com

On Fri, 07 Nov 2003 10:56:37 GMT, "1Sconosciuto" <o...@unknown.invalid>
wrote:

BoundChecker fa esattamente questo: monitorizza accessi alla memoria,
parametri alle API, etc, sia all'interno della modalita' di debug di
VC sia stand alone (cioe' lo lanci come applicazione e da li carichi
il tuo exe da controllare). Quando usavo il Borland C++ 5.02a in
dotazione era compreso CodeGuard che faceva la stessa cosa.
Secondo me l'uso di un programma del genere e' _praticamente_
necessario per programmi C++ un po' piu' complessi di "Hello World",
ti permette veramente di sviluppare programmi stabili come la roccia,
ammesso di avere la pazienza di effettuare complete (e lunghe)
sessioni di debug.
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

Diego ha scritto:

A questo punto io mi pongo una domanda: ma se io tento di scrivere o
leggere in un indirizzo che non ho allocato, e che quindi non esiste nel
mio spazio di indirizzamento, cosa succede esattamente? Qual'è l'indirizzo
fisico sul quale viene effettuata l'operazione (dato che l'indirizzo
fisico in modalità protetta non dovrebbe coincidere con quello che vedo
io)? L'operazione di lettura/scrittura viene realmente effettuata? Windows
reagisce in qualche modo? Non dovrebbe lanciare un'eccezione?
Mi sono accorto di aver fatto cinque domande anziché una... :-)
Io a dire il vero non mi sono mai posto questi problemi perché spesso uso
Visual C++ e quando faccio il debug di tanto in tanto controllo nella
finestra di output che non ci siano memory leaks; in più quando uso MFC,
in modalità debug viene effettuata una mappatura della memoria, perciò se
uno dei numerosi check (che vengono eseguiti solo nel debug) fallisce,
scatta un'asserzione (trovo che tutti questi meccanismi siano molto
comodi, oltre che interessanti).
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers
                               and beta testers are welcome!

 Non dovrebbe lanciare un'eccezione? 
no. Non confondiamo il sistema operativo con malloc


 no. Non confondiamo il sistema operativo con malloc
grazie x la risposta.
ma allora cosa succede realmente? qual'è l'indirizzo nel quale io vado
fisicamente a scrivere? l'operazione di scrittura viene realmente
effettuata? e quella di lettura?


precedentemente allocate dallo stesso?
No, non c'č.  La protezione da parte del sistema operativo e del
processore serve proprio a questo.  In generale, non puoi sapere se il
valore di un puntatore č "valido" nel senso di "indirizzabile senza
problemi".  L'accesso a memoria non allocata genera un "undefined
behavior".  Il problema non viene affatto risolto usando il C++, come
ti č stato erroneamente consigliato.

 che non devo.
Ciao, come ti hanno già risposto, correttamente, il problema è insito
nell'architettura e quindi non c'è modo e il C++ in se non è la soluzione
perché anche quì, se ti riferisci ad un puntatore non inizializzato il tuo
S.O. potrebbe combinarne di tutti i colori.
Se però il problema non è tanto il controllo in sé della validità di un
puntatore, ma cerchi semplicemente allocazioni più "sicure", l'uso dei
contenitori standard del C++ rispetto ai malloc() e free() del C ti consente
di solito la scrittura di codice robusto e generalmente "pulito".
Poi il C++ ha i costruttori e i distruttori che pongono i dati in uno stato
inizializzato, e liberano (se lo prevedi nelle classi che crei) la memoria
eventualmente allocata
Per fare un esempio semplice-semplice, tanti programmatori in erba combinano
un sacco di guai quando devono allocare liste di stringhe C e si perdono
nelle varie allocazioni... in qesto caso un vettore di stringhe o una lista
di stringhe semplifica notevolmente la vita... un altro caso sono gli
auto_ptr nella gestione delle eccezioni in C++, sono tutte cose che non
risolvono il problema ma aiutano nella scrittura di codice robusto!
Come linea guida, quando puoi usa i contenitori della STL, poi, devi stare
attento tu a quello che fai!
Se hai problemi concreti: posta messaggi.
Ciao.