Utilizarea şi programarea calculatoarelor 2 - Laborator 3

Erori de compilare şi interpretarea lor

În practica programării, e absolut necesar să ne obişnuim să înţelegem şi să corectăm singuri erorile de compilare. E bine de asemenea, pe măsură ce realizăm programul pas cu pas, şi am ajuns la o fază intermediară consistentă, să îl compilăm. Adeseori, mai ales pentru programatorii aflaţi la început, erorile de compilare ne pot semnala şi probleme de logică a programului (folosirea incorectă a tipurilor, sau a unor funcţii standard), iar descoperirea lor cât mai timpurie evită pierderea timpului.

Ca mai toate compilatoarele, gcc încearcă să localizeze cât mai precis cauza erorii şi prefixează fiecare mesaj cu linia în care apare eroarea în fişier:
/home/upc/test.c:16 mesaj de eroare propriu-zis
Uneori eroarea se poate afla de fapt puţin înaintea punctului în care ea a fost detectată; în orice caz e bine să ne obişnuim să corectăm erorile pe rând, în ordinea apariţiei, pentru că o eroare gravă poate determina la rândul ei semnalarea a multe alte erori (şi invers, înlăturarea ei poate reduce din numărul mesajelor ulterioare).

Mesaje de eroare

Câteva din cele mai întâlnite mesaje, cu cauzele lor posibile şi exemple de cod în care apar, sunt indicate mai jos:

syntax error at end of input
Mesajul nu e foarte specific; compilatorul a ajuns la sfârşit de fişier şi a găsit că acesta nu se termină în mod corespunzător. Cel mai adesea, asta înseamnă lipsa unei acolade, sau dimpotrivă, cod care de fapt e scris în afara unei funcţii. Putem indenta programul corect, verifica potrivirea acoladelor, şi evita această eroare prin împerecherea lor de la bun început şi respectarea regulilor de indentare.
parse error before 'fp'
file fp;
Tipul file este necunoscut; ar trebuie să fie FILE (de fapt, FILE *, şi trebuie inclus stdio.h). Eroarea e raportată puţin mai târziu, la încercarea declarării lui fp.
parse error before începutul unei instrucţiuni
Cel mai adesea, instrucţiunea dinainte nu a fost încheiată cu ;
`x' undeclared (first use in this function)
Cea mai simplă eroare: folosirea unei variabile nedeclarate. Atenţie însă la alegerea numelor de variabile: , pentru a
break statement not within loop or switch
Instrucţiunea break poate fi folosită numai în interiorul unui ciclu (do, for sau while) sau în instrucţiunea switch. Frecvent, eroarea apare când s-au uitat acoladele în jurul unui şir de instrucţiuni intenţionat ca instrucţiune compusă; în acest caz, doar prima instrucţiune face parte din ciclu, restul sunt în afara lui.
invalid lvalue in assignment
if (!fp = fopen("fisier.txt", "r")) /* ... */
Atribuirea având precedentă scăzută, se evaluează întâi !fp, şi se interpretează expresia ca o incercare de a-i atribui o valoare, fapt eronat pentru că !fp este o expresie oarecare, nu este o variabilă şi nu poate fi atribuită (la fel cum nu poate fi atribuit x + 3 = y).

Mesaje de avertisment

Deşi programul compilează cu succes, aceste mesaje trebuie urmărite cu atenţie. Foarte des, ele semnalează erori logice în program (atribuiri în loc de comparaţii, atribuiri sau parametri cu tip greşit), care sunt dificil de detectat altfel la rulare. E important să ne obişnuim să scriem programe care NU generează mesaje de avertisment.

warning: passing arg 1 of `strlen' makes pointer from integer without a cast
l = strlen(p[i]); /* cu char *p; int i, l; */
S-a transmis un întreg (caracter) pe post de parametru acolo unde ar fi fost nevoie de un pointer. Pentru a corecta eroarea, trebuie verificat în pagina de manual ce fel de parametri ia funcţia respectivă şi ce reprezintă ei. În cazul în care programul e compilat cu opţiunea -Wall şi nu a fost inclus fişierul string.h cu declaraţia lui strlen se va raporta în plus:

warning: implicit declaration of function `strlen'
Folosirea funcţiilor fără a fi declarate nu e recomandabilă pentru că nu dă compilatorului posibilitatea să verifice corespondenţa tipurilor dintre parametrii formali (din declaraţie) şi cei actuali (din apel), ceea ce este o frecventă sursă de erori. Pentru fiecare funcţie standard folosită trebuie deci inclus fişierul antet corespunzător.

warning: suggest parentheses around assignment used as truth value
if (c = getchar() != EOF) /* ... */
Compilatorul avertizează că o atribuire e folosită pe post de valoare de adevăr într-un test. Aici, != are precedenţă mai mare, deci valoarea returnată de getchar() e comparată cu EOF, şi rezultatul (o valoare de adevăr, întregul 1 sau 0) e atribuit lui c. Efectul dorit, de atribuire a lui c şi apoi testul de sfârşit de fişier se obţine cu paranteze: if ((c = getchar()) != EOF) sau cu riscuri mai mici de eroare, simplificând expresia şi folosind instrucţiuni separate: c = getchar(); if (c != EOF) /* ... */.
Acelaşi mesaj e generat şi în cazul unei atribuiri simple folosită ca şi test: if (a = b) care uneori e în intenţia programatorului (ca în while (*s1++ = *s2++); dar adesea e o eroare de neatenţie.

warning: assignment makes pointer from integer without a cast
FILE *fp; if (fp = fopen("fisier.txt", "r") == NULL) exit(1);
Aici, compilatorul a detectat o eroare de logică similară celei de mai sus verificând corespondenţa tipurilor în expresie: valoarea întreagă rezultată din comparaţia între rezultatul lui fopen şi NULL e atribuită unui pointer la fişier. Se dorea de fapt întâi atribuirea lui fp şi apoi compararea: if ((fp = fopen(...)) == NULL). Mesajul apare însă şi în multe alte siţuaţii în care se confuzionează întregi cu pointeri, de exemplu:
char s[20]; char *p; int i; /* câutăm în s, apoi memorăm pozitia */ p = s[i]
Aici, s[i] este un caracter (deci un întreg) şi nu poate fi atribuit pointerului p. Ar trebui p = &s[i].

warning: assignment from incompatible pointer type FILE *fp = argv[1]; Într-o atribuire, atât partea stângă cât şi partea dreaptă sunt pointeri, dar de tip diferit, ceea ce de regulă denotă o eroare logică în program. În exemplul indicat, se face o atribuire de la un argument de pe linia de comandă (care este un şir de caractere) la un fişier, ceea ce este incorect (fp trebuia atribuit cu rezultatul deschiderii (fopen) fişierului cu numele dat). O variantă a mesajului este şi

warning: passing arg 1 of `fprintf' from incompatible pointer type fprintf("numele programului este %s", argv[0]); Unei funcţii care ia ca parametru un pointer (în acest caz fprintf) i se transmite un pointer de tip eronat (primul parametru trebuie să fie FILE * în acest caz).

warning: return type of `main' is not `int' Standardul C prevede că tipul lui main> este int pentru a putea returna un cod sistemului de operare (semnalând terminarea cu succes sau eroare a programului). Dacă nu există intenţia de a interpreta modul de terminare a programului, acest mesaj se poate ignora. Totuşi, e mai frumos să se respecte convenţia şi să se returneze 0 (succes).

warning: control reaches end of non-void function O funcţie care nu e void trebuie să returneze o valoare, pe orice cale de execuţie posibilă prin corpul funcţiei. Dacă compilatorul detectează că se poate atinge acolada de sfârşit } a funcţiei pentru că nu s-a executat explicit un return cu o valoare, el avertizează că în acest caz valoarea returnată de funcţie e nedeterminată.

warning: too few arguments for format int x, y; printf("%d "%d", x); În cazul în care se compilează cu opţiunea -Wall, compilatorul face verificări şi pentru corespondenţa argumentelor la funcţiile de tip printf şi scanf cu format şi număr variabil de argumente (altfel, aceste verificări nu se fac!). Aici, compilatorul a detectat că formatul specifică tipărirea a doi întregi, dar s-a dat ca argument doar unul. (La rulare, programul ar tipări ca a doua valoare conţinutul care se află întâmplător pe stivă în acel loc).

warning: format argument is not a pointer (arg 2) int x; scanf("%d", x); Tot cu opţiunea -Wall, compilatorul avertizează că argumentul 2 care conform formatului ar trebui să fie adresa unde să fie citit întregul, nu este o adresă (ci o valoare de întreg). Corect ar fi fost scanf("%d", &x); Lista de mai sus nu este nici pe departe exhaustivă. La apariţia unui mesaj necunoscut, trebuie să îl citim cu atenţie, (mesajele sunt concise, dar exprimă de regulă precis eroarea), şi apoi să urmărim în detaliu locul indicat în program, regândind ce am dorit să exprimăm cu instrucţiunea respectivă. Marius Minea Last modified: Sun Mar 21 18:52:23 EET 2004