[MISTERO] C corruzione della memoria

[gallows]

Concordo con Mario.

[lamarozzo]

Io invece non sono d'accordo!
Evidentemente Mario anch'io faccio errori idioti come gli utenti Microsoft! Soltanto che è facile definire un errore idiota quando lo hai trovato. Diversa invece è la situazione quando l'errore si nasconde in mezzo a molte righe di codice e passi le ore a riguardare riga per riga. Con quello stupido compilatore Intel, invece, ci metti un secondo a trovarlo.

Il compilatore Intel e` stato creato per M$, ovvio che segnali errori idioti,

Questo è assolutamente falso! Il compilatore Intel viene usato in tutti i centri di calcolo su cluster Linux molto più che il compilatore gcc perchè in media è il 20% volte più veloce. E su codici che girano per mesi è un bel vantaggio.

P.S. Non mi lamento di gcc, che è l'unico che uso. E' ovvio che su architetture Intel il compilatore Intel si comporti meglio. Ma da qui a farlo passare per un compilatore di serie B ce ne corre.

[Mario Vanoni]

Io invece non sono d'accordo!
Evidentemente Mario anch'io faccio errori idioti come gli utenti Microsoft! Soltanto che è facile definire un errore idiota quando lo hai trovato. Diversa invece è la situazione quando l'errore si nasconde in mezzo a molte righe di codice e passi le ore a riguardare riga per riga. Con quello stupido compilatore Intel, invece, ci metti un secondo a trovarlo.

Il compilatore Intel e` stato creato per M$, ovvio che segnali errori idioti,

Questo è assolutamente falso! Il compilatore Intel viene usato in tutti i centri di calcolo su cluster Linux molto più che il compilatore gcc perchè in media è il 20% volte più veloce. E su codici che girano per mesi è un bel vantaggio.

P.S. Non mi lamento di gcc, che è l'unico che uso. E' ovvio che su architetture Intel il compilatore Intel si comporti meglio. Ma da qui a farlo passare per un compilatore di serie B ce ne corre.

lamarozzo, non volevo offenderti, ma permetti una critica:

se tra migliaia di righe di codice il programmatore mette

static double R[8]
...
R[8] = 2.; /* e sarebbe stato piu` esplicito R[8] = 2.0; */
/* cosi` e` indubbiamente un double/float, per di piu` more leggibile */

per me non ha letto K&R, non sa leggere o non conosce C/UNIX.

Il portable C compiler di AT&T SVR2 (1985) sopportava molte imprecisioni,
le ho pagate nel 1996 passando a UNIX SVR3.2 poi Linux con gcc-2.5.8.

Ai tempi (1985) M$ era Intel 8088 8bit, io avevo un AT&T WE32000 32bit!
Con 512MB di memoria, ogni bit contava, ogni recursione inutile ...

Che Intel con i suoi processori attuali sia migliorata nella performance,
quindi icc sia meglio di gcc, non lo metto in dubbio.

Il problema rimane ... e rimarra` sempre il programmatore.

Mario Vanoni

[albatros]

Il problema rimane ... e rimarra` sempre il programmatore.

Ah, questo è sicuro!
Come recita la firma di un mio amico che lavora al CINECA:
"Un computer non fa quello che vuoi, fa quello che gli dici"!

Detto questo e pur concordando che l'errore dovrebbe essere ovvio per chiunque conosca anche solo le basi del C, tuttavia fra migliaia di righe di codice una disattenzione o un errore di battitura può sempre capitare, magari perché poco prima uno ha scritto in un linguaggio dove gli indici partono da 1 (es. ha lavorato con delle liste in Maple)...
Confesso di non sapere quanto sia difficile o oneroso in termini di prestazioni del compilatore implementare in gcc un controllo degli indici in un array, così su due piedi direi abbastanza poco, tuttavia, per quanto non la consideri una feature importante, concordo con lamarozzo che sarebbe utile, anche perché i programmi sono fatti anche per far risparmiare tempo all'uomo e non trovo granché istruttivo perdere tempo alla ricerca di un errore così banale...

[Mario Vanoni]

Il problema rimane ... e rimarra` sempre il programmatore.

Ah, questo è sicuro!
Come recita la firma di un mio amico che lavora al CINECA:
"Un computer non fa quello che vuoi, fa quello che gli dici"!

Detto questo e pur concordando che l'errore dovrebbe essere ovvio per chiunque conosca anche solo le basi del C, tuttavia fra migliaia di righe di codice una disattenzione o un errore di battitura può sempre capitare, magari perché poco prima uno ha scritto in un linguaggio dove gli indici partono da 1 (es. ha lavorato con delle liste in Maple)...
Confesso di non sapere quanto sia difficile o oneroso in termini di prestazioni del compilatore implementare in gcc un controllo degli indici in un array, così su due piedi direi abbastanza poco, tuttavia, per quanto non la consideri una feature importante, concordo con lamarozzo che sarebbe utile, anche perché i programmi sono fatti anche per far risparmiare tempo all'uomo e non trovo granché istruttivo perdere tempo alla ricerca di un errore così banale... :)

albatros, quindi secondo te

- il programmatore dice che cosa deve fare il computer
- il computer lo fa` alla lettera, ma non quello voluto

quintessenza:

- il compilatore deve essere piu` intelligente del programmatore

Mario Vanoni

[albatros]

@Mario Vanoni:
No, era solo per dire che, per ottenere ciò che si vuole da una macchina, bisogna stare molto attenti al codice che si scrive, ovvero era un sostegno alla tua affermazione che il problema, spesso, sta nel programmatore o perlomeno nella superficialità con cui ha programmato.

Quanto al compilatore, se è probabilmente vero che in molti casi è in grado di ottimizzare il codice meglio di un programmatore di medio livello, certamente non è in grado di produrre autonomamente del codice né è in grado di pensare o ragionare in maniera astratta, si limita appunto a tradurre nel miglior modo possibile, secondo schemi prefissati, del codice...
Però il programmatore può distrarsi un attimo o può commettere inavvertitamente un errore anche in qualcosa che sa fare molto bene, magari perché è stanco, perché è preoccupato per qualche motivo, perché ha fretta, perché si sente poco bene, capita spesso di leggere errori di battitura in un testo in parole che credo sia ben noto a tutti come si scrivono oppure capita di notare articoli mancanti o altri errori da elementari, per cui, ripeto, avere la possibilità che un programma stupido, ma dannatamente più veloce di un uomo, possa controllare anche errori stupidi fatti una persona intelligente non la ritengo una idea stupida.
A me è capitato più volte che il compilatore mi segnalasse un errore per una variabile non dichiarata per poi scoprire che l'avevo scritta male o comunque errori che in realtà erano solo di battitura (es ieri avevo una classe QMessage... e ho scritto QtMessage...): perché una volta non mi potrebbe succedere, in un programma lungo, verso fine giornata, di scrivere 8 anziché 7?
Un warning o un controllo da avviare al bisogno non credo faccia male a nessuno, né credo incoraggi a programmare male...

Saluti.

[Mario Vanoni]

@Mario Vanoni:
No, era solo per dire che, per ottenere ciò che si vuole da una macchina, bisogna stare molto attenti al codice che si scrive, ovvero era un sostegno alla tua affermazione che il problema, spesso, sta nel programmatore o perlomeno nella superficialità con cui ha programmato. :)

Quanto al compilatore, se è probabilmente vero che in molti casi è in grado di ottimizzare il codice meglio di un programmatore di medio livello, certamente non è in grado di produrre autonomamente del codice né è in grado di pensare o ragionare in maniera astratta, si limita appunto a tradurre nel miglior modo possibile, secondo schemi prefissati, del codice...
Però il programmatore può distrarsi un attimo o può commettere inavvertitamente un errore anche in qualcosa che sa fare molto bene, magari perché è stanco, perché è preoccupato per qualche motivo, perché ha fretta,
perché si sente poco bene, capita spesso di leggere errori di battitura in un testo in parole che credo sia ben noto a tutti come si scrivono oppure capita di notare articoli mancanti o altri errori da elementari, per cui, ripeto, avere la possibilità che un programma stupido, ma dannatamente più veloce di un uomo, possa controllare anche errori stupidi fatti una persona intelligente non la ritengo una idea stupida. :)
A me è capitato più volte che il compilatore mi segnalasse un errore per una variabile non dichiarata per poi scoprire che l'avevo scritta male o comunque errori che in realtà erano solo di battitura (es ieri avevo una classe QMessage... e ho scritto QtMessage...): perché una volta non mi potrebbe succedere, in un programma lungo, verso fine giornata, di scrivere 8 anziché 7?
Un warning o un controllo da avviare al bisogno non credo faccia male a nessuno, né credo incoraggi a programmare male...

Saluti. :D

Senza dubbio "Errare humanum est", ma evitiamo per favore
di attribuire ad un compilatore (sfogliare ZINGARELLI: compilatore)
dellle possibilita` che non avra` mai!

Non si puo` incolpare il ferro da calza, se si sbaglia un punto a maglia
e se lo si scopre a pullover ultimato.

Mario Vanoni

[albatros]

(sfogliare ZINGARELLI: compilatore)

Dallo Zingarelli 1995, significato B:

compilatore: Programma che traduce in codice macchina le istruzioni critte in un linguaggio simbolico, in modo che il programma oggetto risultante possa essere letto ed eseguito dall'elaboratore.

D'accordo, se ritieni che un compilatore debba fare "solo" questo, rispettando così in pieno la visione KISS a cui in altri interventi hai più volte accennato, non ho quasi nulla da dire, se non che un compilatore rimane comunque un software molto complesso, oggi e in futuro più che mai, e aggiungere features opzionali facili da implementare secondo me non ne renderebbe più difficile la manutenzione e lo sviluppo. Ma certamente queste funzionalità aggiuntive e non strettamente necessarie, per quanto facili da implementare possano essere, secondo la logica KISS potrebbero essere implementate in un programma a parte, quindi in definitiva, se è questo il tuo pensiero, lo rispetto e in molte circostanze lo condivido anche.

evitiamo per favore di attribuire ad un compilatore (sfogliare ZINGARELLI: compilatore) dellle possibilita` che non avra` mai!

Beh, se per compilatore intendi solo la definizione riportata sopra no, appunto per definizione, altrimenti queste possibilità può averle, dato che ICC, che viene chiamato anch'esso compilatore, forse abusivamente, impropriamente o per una specie di sineddoche, ce l'ha...

A scanso di equivoci, è evidente che l'episodio riportato nel post precedente dal punto di vista del compilatore è molto diverso, la citazione serviva solo per dire che, oltre ad errori concettuali, si possono commettere a volte errori di distrazione o di battitura molto banali...

Non si puo` incolpare il ferro da calza, se si sbaglia un punto a maglia e se lo si scopre a pullover ultimato.

No, per forza, perché il ferro non può fare alcunché per segnalare un errore, però i programmi per pc sono o possono essere scritti anche per aiutare a individuare e correggere alcuni errori umani.
D'accordo, un compilatore non è tenuto a individuare certi tipi di errore e se, secondo te, un compilatore deve compilare e basta, è finita la discussione. Secondo me, però, si possono aggiungere anche alcuni "optional" più o meno utili, così come si aggiungono alle automobili, che pure dovrebbero servire a spostarsi e basta, per rendere più confortevole il viaggio, purché siano attinenti e complementari allo scopo principale del programma e non influenzino negativamente il suo sviluppo, così come sembrerebbe a me in questo caso.
Per adesso non ho mai sbagliato gli indici di un array statico, né, pur non avendone certezza, credo di farlo in futuro e non sento il bisogno di avere il conforto di gcc che mi avverte anche degli errori più banali, né potrei mai pretendere che gcc faccia un controllo semantico o che sia in grado di scoprire tutti i miei errori, però valuterei positivamente qualsiasi aiuto possa essere ragionevolmente fornito allo sviluppatore, ferma restando l'assoluta priorità della capacità del compilatore di compilare piuttosto che di correggere gli errori.

Saluti.

[Mario Vanoni]

@albatros

Grazie per la pena di scrivere tanto, ma

gli optional nelle auto non tolgono responsabilata` al guidatore

array statici vent'anni fa:
se ne aggiungeva uno in piu`, chiamato sentinel(la),
a volte e` servito, poche veramente, una tantum ...

Mario Vanoni

[albatros]

gli optional nelle auto non tolgono responsabilata` al guidatore

Sono d'accordo.

[lamarozzo]

Mario non me l'ero presa, volevo solo esprimere meglio il mio punto di vista. Siamo d'accordo che l'errore è un errore di distrazione. Dato che questo tipo di errori accadono (e penso anche che siano la maggioranza) la mia tesi voleva solo sostenere che sarebbe bene per un compilatore venire in aiuto del programmatore.

Secondo me la tua idea (e quella dello Zingaretti) di compilatore è troppo semplicistica. Il compilatore non si limita a tradurre il sorgente in codice macchina. Se così fosse non esisterebbero tutte le migliaia di ottimizzazioni che i compilatori eseguono sul codice. Si tratta di operazioni sul codice che il programmatore potrebbe farsi anche a manina (unroll dei cicli, padding della memoria, ecc.) ma che, poichè la pazienza umana è finita, viene delegata al compilatore. Come vedi quindi ogni volta che compili stai affidando al compilatore milioni di operazioni che non hai richiesto espressamente e che vengono fatte perchè si ritiene siano utili. E allo stesso livello di utilità si collocano anche i messaggi di errore. E' vero che lo standard non li prevede (come le ottimizzazioni) ma sono comodissime, e alla fine contano sul giudizio che si dà ad un software.

Ovviamente IMO.

P.S. Scrivere 2. invece di 2.0 è perfettamente lecito; cito proprio K&R: "Either the integer part or the fraction part (not both) may be missing ...

[Mario Vanoni]

Mario non me l'ero presa, volevo solo esprimere meglio il mio punto di vista. Siamo d'accordo che l'errore è un errore di distrazione. Dato che questo tipo di errori accadono (e penso anche che siano la maggioranza) la mia tesi voleva solo sostenere che sarebbe bene per un compilatore venire in aiuto del programmatore.

Secondo me la tua idea (e quella dello Zingaretti) di compilatore è troppo semplicistica. Il compilatore non si limita a tradurre il sorgente in codice macchina. Se così fosse non esisterebbero tutte le migliaia di ottimizzazioni che i compilatori eseguono sul codice. Si tratta di operazioni sul codice che il programmatore potrebbe farsi anche a manina (unroll dei cicli, padding della memoria, ecc.) ma che, poichè la pazienza umana è finita, viene delegata al compilatore. Come vedi quindi ogni volta che compili stai affidando al compilatore milioni di operazioni che non hai richiesto espressamente e che vengono fatte perchè si ritiene siano utili. E allo stesso livello di utilità si collocano anche i messaggi di errore. E' vero che lo standard non li prevede (come le ottimizzazioni) ma sono comodissime, e alla fine contano sul giudizio che si dà ad un software.

Ovviamente IMO.

P.S. Scrivere 2. invece di 2.0 è perfettamente lecito; cito proprio K&R: "Either the integer part or the fraction part (not both) may be missing ...

Esatto, ma un 2.0 e` piu` leggibile di un 2.
Invecchiando gli occhi peggiorano, un punto stampato sbiadisce ...
Rileggi il codice tra tre anni quando sara` solo un ricordo dei tempi ...

Il compilatore lo aiuti tu, mettendo sentinelle, controllando i valori di ritorno,
se falsi o improbabili con messaggio d'errore, dove possibile inizializzando
variabili con valori impossibili, p. e. double R = 99.99,
nei case con un default con messaggio "This should never happen" ecc.
Devi prevedere l'impossibile perche` ci sara` sempre un utente che,
anche involontariamente, ti [pt]rovera` una situazione non pensata.

Mario Vanoni

[puzuma]

Il compilatore lo aiuti tu, mettendo sentinelle, controllando i valori di ritorno,
se falsi o improbabili con messaggio d'errore, dove possibile inizializzando
variabili con valori impossibili, p. e. double R = 99.99,
nei case con un default con messaggio "This should never happen" ecc.
Devi prevedere l'impossibile perche` ci sara` sempre un utente che,
anche involontariamente, ti [pt]rovera` una situazione non pensata.

il problema è che siamo uomini e non macchine, nella mia esperienza utilizzo queste tecniche in tutti i miei programmi, ogni tanto però (purtroppo l'interfaccia usb attaccata al cervello non ce l'ho ancora) capita di fare la "c***ata", se il compilatore è così furbo da dirmi "guarda tra queste 100.000 righe di codice forse hai fatto un errore qui" sono ultrafelice, mi fa risparmiare una settimana di lavoro che posso occupare in altro modo (e soprattutto non regalerò mai un vocabolario agli sviluppatori intel

[lamarozzo]

Sono d'accordo. I programmatori devono cercare di prevenire tutte le mosse sbagliate dell'utente. In più aggiungerei che chi scrive un compilatore deve cercare di prevenire al meglio tutte le possibili mosse sbagliate dei suoi utenti, cioè i programmatori. E' solo questione di punti di vista, ma penso che in fondo stiamo dicendo le stesse cose.

[Mario Vanoni]

Il compilatore lo aiuti tu, mettendo sentinelle, controllando i valori di ritorno,
se falsi o improbabili con messaggio d'errore, dove possibile inizializzando
variabili con valori impossibili, p. e. double R = 99.99,
nei case con un default con messaggio "This should never happen" ecc.
Devi prevedere l'impossibile perche` ci sara` sempre un utente che,
anche involontariamente, ti [pt]rovera` una situazione non pensata.

il problema è che siamo uomini e non macchine, nella mia esperienza utilizzo queste tecniche in tutti i miei programmi, ogni tanto però (purtroppo l'interfaccia usb attaccata al cervello non ce l'ho ancora) capita di fare la "c***ata", se il compilatore è così furbo da dirmi "guarda tra queste 100.000 righe di codice forse hai fatto un errore qui" sono ultrafelice, mi fa risparmiare una settimana di lavoro che posso occupare in altro modo (e soprattutto non regalerò mai un vocabolario agli sviluppatori intel :-)

Per la sintassi sono concorde.

Ma se in un input, da un utente qualunque o da un programma,
non prevedi la "c***ata" che puo` fare lui o immettere il programma,
e il tuo codice non lungimirante fa che accada, l'errore e` tuo, unicamente tuo.
Qui serve unicamente il cervello umano, stanco/fuso che sia!

Mario Vanoni