[MISTERO] C corruzione della memoria

[Simone_R]

vorrei sviluppare un po' l'esempio

Codice: Seleziona tutto

#include<stdio.h>

static double R[8];

int main()
{
        printf("%lf\n",R[8]);
        return 0;
}

L'output del codice è 0.00000

Ora ho fatto girare questo codice con Valgrind e non rileva nulla. Il fatto secondo me è preoccupante perchè lo standard prevede che gli array statici vengano inizializzati a zero. Soltanto che l'inizializzazione non dovrebbe riguardare anche l'elemento R[8] perchè non fa parte dell'array. Quindi sto leggendo una zona di memoria che in teoria neanche dovrebbe essere inizializzata e niente mi avverte dell'errore. Perchè?
[

Perché il compilatore la potrebbe aver inizializzata a zero per altri motivi.
Perché prima c'era scritto zero (quando accendi il PC le celle sono a zero).
Perché è una zona di memoria inutilizzata.
In genere la lettura è sempre autorizzata.

Ti può dare errore (segmentetion fault) solo se esci dai blocchi memoria assegnati dal kernel al tuo programma.
I blocchi assegnati dal kernel hanno una dimensione costatante quindi se allochi 10 celle il sistema te ne assegna in un botto 4000 [adesso non ricordo la dimensione esatta di un singolo blocco].

In genere il segmentation fault viene dato solo se tenti di violare lo spazio assegnato ad un altro processo quindi il kernel tollera che si sfori dai blocchi asseganti a condizione che non si disturbi nessuno.

[lamarozzo]

ma io non volevo un segmentation fault. Volevo che Valgrind, o chi per lui, mi dicesse: "Ehi, stai leggendo in una zona di memoria non inizializzata dal tuo programma!".

P.S. Non voglio assolutamente criticare programmi tipo Valgrind, che sono dei software meravigliosi, che molte volte mi hanno tirato fuori da impicci ben peggiori. Lo scopo della discussione alla fine è quello di far capire che non bisogna porre una fiducia cieca in questi programmi di debugging della memoria. Io una volta lo facevo, ma come si vede ci sono casi d'uso del C che questo tipo di programmi non coprono.

[Mario Vanoni]

ma io non volevo un segmentation fault. Volevo che Valgrind, o chi per lui, mi dicesse: "Ehi, stai leggendo in una zona di memoria non inizializzata dal tuo programma!".

P.S. Non voglio assolutamente criticare programmi tipo Valgrind, che sono dei software meravigliosi, che molte volte mi hanno tirato fuori da impicci ben peggiori. Lo scopo della discussione alla fine è quello di far capire che non bisogna porre una fiducia cieca in questi programmi di debugging della memoria. Io una volta lo facevo, ma come si vede ci sono casi d'uso del C che questo tipo di programmi non coprono.

Permettimi l' _ultima_ considerazione:

Se programmi in C, sei un essere libero come un uccello, pero`,
devi essere cosciente di quello che fai, al 100% responsabile.
Non ci saranno _mai_ tools come speri, quindi arrenditi all'evidenza.

Mario Vanoni

[sir_alex]

Aridaje... Perchè devono inserire un controllo su una cosa non prevista dal linguaggio?

comunque non ho mai detto (io ) nulla in merito ai programmatori in questione in questo topic. Personalmente, ho fatto errori ben peggiori, e non solo in C. Credo che si possa affermare che sbagliare sia un passo fondamentale del processo d'apprendimento, per cui nulla di male. Inoltre, se tutti sapessero tutto e facessero tutto giusto fin dall'inizio, a cosa diavolo servirebbe questo forum? ^_^

Secondo me i programmatori di Intel l'hanno aggiunto perchè Intel, come Microsoft, è una corporate, e fa quello che vuole. Quante cose ha fatto Microsoft che fanno cacare? Il fatto che lei le abbia fatte significa forse che son giuste? No.

Allo stesso modo, implementare controlli sulle [] allo scopo di usarle come array, è errato, MOLTO errato, perchè non sono il tipo di dato array. Per questo, io credo sia MEGLIO che gcc non supporti controlli di questo tipo, perchè così quando vuoi usare array come tipo dati, non essendo supportati dal linguaggio te li devi per forza programmare, sei obbligato.
Con il compilatore di intel invece puoi darla vinta alla pigrizia ed usare le [] per qualcosa che non sono in grado di fare.

Purtroppo non ho nessun manuale di C e quindi non posso verificare nulla, ma [] è un operatore per creare array. Punto. Non ha alcun senso dire che per fare degli array devi crearti tu una libreria, giustificando il fatto che [] non è adatto: non è vero. Ok, ha senso dire che se ti fai una libreria è meglio perchè puoi aggiungere tu i controlli che C non ha di default (come lo sforare appunto gli array), ma dire che fare array con [] è errato è campato in aria! Altrimenti per che cosa diavolo servono le parentesi quadre? L'unico uso che io conosco è questo!
Poi, ripeto, magari ho completamente sbagliato, non ho un manuale, ma a me ad Info 1 hanno insegnato così e non vedo perchè il prof dovrebbe dire cavolate...
Per il discorso del topic invece, secondo me avere dei tools che ti indicano i bug di un software sono utili, sono d'accordo con chi dice "non chiamiamoli compilatori", ma d'altronde un compilatore come gcc o icc non fa solo il mestiere che gli dà il nome, fa anche altre cose (come le ottimizzazioni). E', se volete, lo stesso motivo per cui io ritengo (opinione personale) che usare un ambiente di programmazione è molto più utile di scrivere il codice in Vim (o qualunque editor puro), sia esso C, Java, quant'altro: un IDE spesso e volentieri effettua controlli per evitare gli errori "stupidi" (come quello di sforare un array per disattenzione, non per comportamento voluto)...
Ed è assolutamente assurdo dichiarare che chi fa un errore del genere non sa programmare, il saper programmare non ha nulla a che fare con il digitare una lettera per un'altra ad esempio!
Infine, se è vero che Intel e Microsoft fanno quello che vogliono, anche GNU fa quello che vuole quando scrive gcc, e le decisioni sono comunque prese da qualcuno sulla base della sua esperienza professionale o di una decisione magari presa discutendo con altri, ma come ogni discussione è ovviamente opinabile! Se Intel ha 12 cose che non fanno parte dello standard, anche GNU penso abbia implementato altre cose che magari non sono standard ma sono risultate comode da parte di chi ha creato il programma, per questo esistono flag come -ansi, che penso abbia anche icc (con cui purtroppo non ho esperienza).

IMHO

[puzuma]

Non ci saranno _mai_ tools come speri, quindi arrenditi all'evidenza.

bhè, in realtà lui in tool l'ha già trovato: icc, poi cercando in internet tool che verificano questi e altri comportamenti se ne trovano.

[phobos3576]

Lamarozzo, 6 pagine di messaggi per dissertare su una caratteristica che è peculiare del C; te lo hanno già spiegato anche altri: il C è fatto apposta così perché K&R lo volevano così.
Io stesso lo uso perché ho la necessità di sconfinare dai limiti di un array; il compilatore e il debugger non possono avvertirti perché ciò non avrebbe nessun senso.

Il Pascal è stato progettato per i bambini dell'asilo per cui ti avverte se eccedi dai limiti di un array; un bravo programmatore però può utilizzare i puntatori per aggirare facilmente le regole del compilatore Pascal.
Per maggiori dettagli puoi leggerti gli ultimi tre capitoli della sezione Assembly Base dei miei tutorial:

http://xoomer.alice.it/ramsoft/

Se vuoi che il C esegua dei controlli sui limiti di un array, devi necessariamente evitare la definizione diretta dell'array stesso; al suo posto devi usare una apposita struct che incapsula l'array e fornisce funzioni di accesso che ti permettono di manipolare indirettamente il vettore con tanto di controllo automatico degli eventuali errori.

Meglio ancora, passando al C++ puoi scriverti una classe di tipo array capace di svolgere tutti i controlli possibili e immaginabili.

Stai attento però a non chiedere a Linus Torvalds: "perchè non usi il C++?"

[puzuma]

dalla wikipedia:

A buffer overflow is an anomalous condition where a process attempts to store data beyond the boundaries of a fixed-length buffer. The result is that the extra data overwrites adjacent memory locations. The overwritten data may include other buffers, variables and program flow data and may cause a process to crash or produce incorrect results. They can be triggered by inputs specifically designed to execute malicious code or to make the program operate in an unintended way. As such, buffer overflows cause many software vulnerabilities and form the basis of many exploits. Sufficient bounds checking by either the programmer, the compiler or the runtime can prevent buffer overflows.

posso capire che alcuni programmatori sanno gestire queste cose prima di colazione, ma almeno un piccolo warning per avvertire che potenzialmente si sta esponendo il nostro programmino a tutta una serie di pericoli non mi sembra una richiesta così assurda.

Mica vi stiamo imponendo di usarlo o di non programmare così, semplicemente a molti questo warning è molto utile.

perchè vi da così fastidio un controllo così idiota non lo capisco proprio.[/code]

[phobos3576]

posso capire che alcuni programmatori sanno gestire queste cose prima di colazione, ma almeno un piccolo warning per avvertire che potenzialmente si sta esponendo il nostro programmino a tutta una serie di pericoli non mi sembra una richiesta così assurda.

Mica vi stiamo imponendo di usarlo o di non programmare così, semplicemente a molti questo warning è molto utile.

perchè vi da così fastidio un controllo così idiota non lo capisco proprio.

Miiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

[puzuma]

Miiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

rispondi all'articolo della wikipedia piottosto

[nuitari]

Cercherò di rispondere senza irritarmi..

Purtroppo non ho nessun manuale di C e quindi non posso verificare nulla, ma [] è un operatore per creare array. Punto. Non ha alcun senso dire che per fare degli array devi crearti tu una libreria, giustificando il fatto che [] non è adatto: non è vero.

A si? Non è vero? Ed in base a che ragionamento?? Prova a fare un "sizeof(array)". Funziona? No. Perchè? Perchè non esiste il tipo "array" in C, che invece è un tipo nei linguaggi che, guarda un po' che caso, supportano il bound checking. Sai cosa significa che un linguaggio non supporta un tipo dati? Bene, in C non esiste un tipo dati per gli array, con tutto quel che comporta.

Lo ripeto: le parentesi quadre sono un operatore che dereferenzia un puntatore. L'ho ampiamente dimostrato nei miei esempi così come ho dimostato che quelli che chiamate array sono puntatori a matrici di dati uguali e nient'altro, che rispondono unicamente all'aritmetica dei puntatori e nient'altro. expr1[expr2] è uguale a *((expr1) + (expr2)), è la stessa cosa in C, non cambia nulla, a nessun fine. L'unica differenza, come è stato evidenziato dal mio esempio, risiede nella compilazione E BASTA.
Il nome di un array viene tradotto in una locazione di memoria, un puntatore è una zona di memoria della dimensione di un puntatore che contiene l'indirizzo dell'area di memoria.

Vuoi dire di no? Dillo. Dillo quanto ti pare. Ma questo non lo renderà vero, finchè non lo dimostri. Dimostra che ai fini del linguaggio C definire una matrice di valori con le parentesi [] rende il suo nome qualcosa di più di un puntatore ad un area di memoria contigua di dimensione sizeof(type) * elementi, e allora FORSE avrai ragione.

Anche se comunque, non avrai ragione lo stesso, e sai perchè?

Perchè i linguaggi di programmazione non devono implementare tutto. Ogni linguaggio implementa quello che vuole come vuole e se vuole. Sono i programmatori che decidono cosa usare e per quale motivo in base alle proprie esigenze e, perchè no, alle proprie capacità.
Se ti riesce così assurdo dividere le parentesi quadre dal tuo concetto di array, non è il C ad essere sbagliato, sei tu che stai sbagliando linguaggio.
E se ti mettessi a programmare in assembler allora, che è pure più povero, che diresti?

Ok, ha senso dire che se ti fai una libreria è meglio perchè puoi aggiungere tu i controlli che C non ha di default (come lo sforare appunto gli array), ma dire che fare array con [] è errato è campato in aria! Altrimenti per che cosa diavolo servono le parentesi quadre? L'unico uso che io conosco è questo!

Mi spiace che tu conosci solo quest'utilizzo, davvero. Ma ho dimostrato che ce ne sono altri. Li hai letti o no? Come fai a saltare fuori e dire che non c'è altro ultilizzo quando l'ho spiegato negli altri post e dimostrato con degli esempi di codice??????

Poi, ripeto, magari ho completamente sbagliato, non ho un manuale, ma a me ad Info 1 hanno insegnato così e non vedo perchè il prof dovrebbe dire cavolate...

Sai ad un certo galileo tutti dicevano che il sole girava attorno alla terra... pensa te!
Ma perchè, credi che il tuo prof ti abbia detto solo questa cavolata? Evidentemente deve darsi una ripassata di C o spiegarlo un po' meglio.

Per il discorso del topic invece, secondo me avere dei tools che ti indicano i bug di un software sono utili, sono d'accordo con chi dice "non chiamiamoli compilatori", ma d'altronde un compilatore come gcc o icc non fa solo il mestiere che gli dà il nome, fa anche altre cose (come le ottimizzazioni). E', se volete, lo stesso motivo per cui io ritengo (opinione personale) che usare un ambiente di programmazione è molto più utile di scrivere il codice in Vim (o qualunque editor puro), sia esso C, Java, quant'altro: un IDE spesso e volentieri effettua controlli per evitare gli errori "stupidi" (come quello di sforare un array per disattenzione, non per comportamento voluto)...
Ed è assolutamente assurdo dichiarare che chi fa un errore del genere non sa programmare, il saper programmare non ha nulla a che fare con il digitare una lettera per un'altra ad esempio!

E chi decide cosa è disattenzione e cosa no? Se gcc mi segnalasse cosa è disattenzione e cosa no SECONDO LUI, ne morirei. Sarebbe la prima opzione che disabiliterei, così come disabiliterei il codice che LUI genererebbe runtime per controllare quello che LUI suppone io voglia gestire come array o su cui LUI suppone io voglia avere dei controlli.. per carità di dio. E sai perchè? Perchè generalmente con il C si programmano cose a basso livello. Se si vuole programmare un software per, che so, calcolare quanto è stato speso in un mese per la gestione della casa, il C non è il linguaggio giusto (che una cosa si possa fare con uno strumento, non vuol dire che sia giusto farla con quello strumento. Prova a cuocere una pizza con un fornellino da campeggio... farlo puoi farlo.. ma... suvvia!)

Infine, se è vero che Intel e Microsoft fanno quello che vogliono, anche GNU fa quello che vuole quando scrive gcc, e le decisioni sono comunque prese da qualcuno sulla base della sua esperienza professionale o di una decisione magari presa discutendo con altri, ma come ogni discussione è ovviamente opinabile! Se Intel ha 12 cose che non fanno parte dello standard, anche GNU penso abbia implementato altre cose che magari non sono standard ma sono risultate comode da parte di chi ha creato il programma, per questo esistono flag come -ansi, che penso abbia anche icc (con cui purtroppo non ho esperienza).

IMHO

E dunque? E' ovvio che ognuno fa quello che vuole. La differenza però è nell'approccio. Vuoi forse paragonare l'approccio della Free Software Foundation a quello di una qualsiasi corporate?

Beh, non ce l'ho fatta a non irritarmi.
Per quanto all'inizio non volevo farlo, mi unisco a Vanoni: chi programma in C, deve sapere cosa sta facendo, perchè il C è un linguaggio che richiede questo: che la gente sappia cosa sta facendo.
Accoglimi nella tua scomoda posizione, Marco

Ci aggiungo solo una postilla: sbagliando s'impara. Invece d'intestardirvi a dire "NOOO! SONO ARRAY PERCHE' IL LIBRO DELLA WILBUR E SMITH DICE CHE SONO ARRAY" ed al contempo fate il salto logico "SICCOME SONO ARRAY ALLORA DEVONO (e sottolineo devono) FARE IL CONTROLLO SUI LIMITI", potete semplicemente prendere atto che il C non funziona così, che quello che vi aspettate che il C faccia NON LO FA e che o imparate a convivere con questa ed altre cose che il C non fa (ad esempio classi/oggetti), oppure cambiate linguaggio. Potreste semplicemente prendere atto che state chiedendo al C qualcosa di sbagliato e che quindi l'errore è vostro, non del C.

Ora flammatemi pure =)

[nuitari]

Lamarozzo, 6 pagine di messaggi per dissertare su una caratteristica che è peculiare del C; te lo hanno già spiegato anche altri: il C è fatto apposta così perché K&R lo volevano così.
Io stesso lo uso perché ho la necessità di sconfinare dai limiti di un array; il compilatore e il debugger non possono avvertirti perché ciò non avrebbe nessun senso.

Il Pascal è stato progettato per i bambini dell'asilo per cui ti avverte se eccedi dai limiti di un array; un bravo programmatore però può utilizzare i puntatori per aggirare facilmente le regole del compilatore Pascal.
Per maggiori dettagli puoi leggerti gli ultimi tre capitoli della sezione Assembly Base dei miei tutorial:

http://xoomer.alice.it/ramsoft/

Se vuoi che il C esegua dei controlli sui limiti di un array, devi necessariamente evitare la definizione diretta dell'array stesso; al suo posto devi usare una apposita struct che incapsula l'array e fornisce funzioni di accesso che ti permettono di manipolare indirettamente il vettore con tanto di controllo automatico degli eventuali errori.

Meglio ancora, passando al C++ puoi scriverti una classe di tipo array capace di svolgere tutti i controlli possibili e immaginabili.

Stai attento però a non chiedere a Linus Torvalds: "perchè non usi il C++?"

quoto in toto quest'uomo.

[phobos3576]

rispondi all'articolo della wikipedia piottosto

Ma che c'entra l'articolo di Wikipedia?

Se devo passare su una bella strada asfaltata uso una Rolls Royce, ma se devo prendere la scorciatoia su una strada sterrata o in mezzo ai monti uso un Fuoristrada.
Ci sono linguaggi di programmazione Rolls Royce e linguaggi di programmazione Fuoristrada; in casi estremi non bastano neppure i linguaggi Fuoristrada e si deve ricorrere ai linguaggi Bulldoozer. Il C e l'Assembly sono linguaggi Bulldoozer!
Se non ti piacciono i linguaggi Fuoristrada e Bulldoozer, usa quelli Rolls Royce; chi te lo impedisce?

Il C è stato concepito in quel modo perché i suoi progettisti volevano la massima libertà d'azione; lo standard ANSI C non prevede esplicitamente il controllo sui limiti degli array per cui sarebbe un controsenso introdurre una simile caratteristica (che appesantirebbe pure i programmi in C) .

[lamarozzo]

Mi viene sempre detto che devo smetterla di chiedere al C cose che non fa. Ma io non l'ho mai chiesto. Ho solo sottolineato che i più comuni tool di debugging della memoria per C non funzionano in alcuni casi. Un tool di debugging della memoria serve a prevenire errori nella gestione della memoria, evidentemente non tutti.

Prima pensavo che con gdb e valgrind e rimboccandosi un po' le maniche si potessero rintracciare tutti gli errori di corruzione della memoria. Purtroppo ora devo aggiungere alla lista anche il compilatore intel, che non è free.

Ora chiedo ai miei critici. Cosa fareste se aveste un problema di corruzione della memoria senza idea di dove avvenga? Vi riguardate riga per riga?

Il C non è linguaggio solo per sistemi operativi e driver (vedasi Gnome). Non ci vedo niente di male ad avere tool che aiutino il debugging delle applicazioni.
Se ogni volta che uno ha un problema come il mio gli venisse detto "non sai programmare in C, la libertà ha un prezzo" a quest'ora probabilmente non ci sarebbero tool come Valgrind. E probabilmente il C sarebbe ancor più un linguaggio di nicchia.

P.S. Se provassi a chiedere a Torvalds perchè non programma in C++ probabilmente la prossima versione del kernel uscirebbe con una licenza che mi vieta di usarlo

[lamarozzo]

... lo standard ANSI C non prevede esplicitamente il controllo sui limiti degli array per cui sarebbe un controsenso introdurre una simile caratteristica (che appesantirebbe pure i programmi in C) .

phobos se ti rileggi i post ti accorgi che noi non stiamo parlando di nessun controllo run-time del compilatore C. Semplicemente un warning del compilatore (come fa icc) oppure un tool che ti aiuta a scovare le situazioni in cui leggi variabili statiche non inizializzate.

[sir_alex]

1) no, non paragono il comportamento di GNU e di un'azienda (grazie a Dio sono diversi), ma ritengo che _tutti_ i compilatori abbiano opzioni per compilare codice seguendo alcuni standard (come ANSI) ed altre che permettono di eseguire "cose" aggiuntive da loro scritte
2) sono d'accordo sull'uso del C, non è assolutamente vero che è solo per driver ma in ogni caso io non lo uso (più) per fare cose come interfacce grafiche eccetera, preferisco usare cose come Java, Python, C# (C++ non lo conosco e soprattutto non ha un GC )
3) [] non sono operatori che deferenziano un puntatore, piuttosto sono i puntatori che danno un metodo alternativo per creare gli array come strutture dati; [] sono operatori per creare ARRAY (che, siamo d'accordo, non sono tipi di dato in C. Ma guarda caso non lo sono neppure in Java. O in C#. O se lo sono, sono trasparenti all'utente), questo dall'articolo "Operators in C and C++" di Wikipedia e dalla definizione ANSI C (che ritengo quella ufficiale, dato che è lo standard internazionale). Se alla fine il comportamento risulta essere lo stesso della deferenziazione, possiamo essere d'accordo, ma ciò non implica necessariamente che siano la stessa cosa. Ah, [] non vengono usati per fare null'altro rispetto alla creazione di array. Almeno, dalla stragrande maggioranza del mondo.
4) Io ritengo che, mediamente, i miei insegnanti non raccontino balle; è ovviamente possibile che sbaglino, chiunque sbaglia, tuttavia, come tutti gli insegnanti di questo mondo, anche quello di cui parlavo insegna ad usare gli array in C. Con []. Vedi punto (3)
5) Abbandoniamo la discussione sul compilatore, e spostiamoci allora su valgrind (che però non ho mai usato) o tools simili, quelli potrebbero anche dire che si sta accedendo ad un frammento di memoria non inizializzato. No? Poi magari tu stai facendo un tool che acceda a memoria riservata ed allora ignori o disabiliti il warning
6) Per l'ennesima volta, io posso conoscere a menadito C ed essere il miglior programmatore del mondo, ma posso comunque sbagliare a scrivere e poi dover fare debug manuale di migliaia di righe di codice, come è capitato nel topic. Se qualcuno mi avverte che alla riga x potrebbe esserci un errore, bè male non fa.