[so] [Macro-ul DIE]
Darius Mihai
dariusmihaim at gmail.com
Tue Mar 6 17:35:05 EET 2018
2018-03-06 17:30 GMT+02:00 Mihai Popescu via so <so at cursuri.cs.pub.ro>:
> Salut,
>
>>Spre exemplu, dacă programul nostru trebuie să iasă ca urmare a altor erori, și nu în urma unei erori a unui apel de sistem, atunci errno-ul va ramâne setat pe Sucess/0, iar programul nostru se va termina cu succes.
>
> Aveți dreptate, exact asta este și ideea. Ce vreau să spun este că
> deoarece mesajul de eroare este afisat cu *perror*, când nu se produce
> o eroare ne este afișat un mesaj de genul
> "mesaj_de_eroare: Success"
> Pe de altă parte, când este o eroare a unui apel de sistem, este
> afișat mesajul bun, dar este returnat alt cod.
> Ceva de genul acesta ar rezolva ambele probleme:
>
> if (assertion) { \
> int err = EXIT_FAILURE; \
> fprintf(stderr, "(%s, %d): ", \
> __FILE__, __LINE__); \
> if (errno) { \
> err = errno; \
> perror(call_description); \
> } \
> else { \
> fprintf(stderr,"%s", call_description); \
> } \
> exit(err); \
> } \
>
Salut,
Macro-ul este, din ce știu, doar un exemplu. Se poate extinde foarte
ușor prin adăugarea unui parametru suplimentar care să reprezinte
codul de eroare pe care doriți să îl întoarceți prin exit.
Darius
>
>> Salut, Mihai!
>>
>> Cum a spus și Adrian, în primul rând nu este OK întotdeauna să întoarcem
>> valoarea errno-ului în caz de eroare. Spre exemplu, dacă programul nostru
>> trebuie să iasă ca urmare a altor erori, și nu în urma unei erori a unui
>> apel de sistem, atunci errno-ul va ramâne setat pe Sucess/0, iar programul
>> nostru se va termina cu succes.
>>
>> O altă mențiune este că majoritatea apelurilor de sistem eșuează cu valoarea
>> -1 (sau valori negative în general), care în bash este translatată la 255.
>> Deși și dacă ai vrea să verifici dacă procesul s-a întors cu o valoare
>> negativă, nu ai putea.
>>
>> Poți să ne dai un exemplu concret în care schimbarea adusă de tine este
>> utilă?
>>
>> Numai bine,
>> Răzvan
>>
>> On Tue, Mar 6, 2018 at 4:39 PM Adrian Pop via so <so at cursuri.cs.pub.ro>
>> wrote:
>>>
>>> Salut!
>>> Nu m-am prins daca ai intrebat sau nu ceva, insa pot sa spun ca nu este
>>> obligatoriu sa:
>>> - folosim DIE (de exemplu in caz ca vrem sa dezalocam memoria, nu este
>>> prea ok)
>>> - intoarcem neaparat codul intors de apelul de sistem, in cazul unei erori
>>>
>>> Pentru partea cu DIE, poti tu pur si simplu sa pui exit(-1) in macro (sau
>>> sa ai un #define FAIL_CODE -1) si asa mereu vei avea un cod de return
>>> negativ (asa cum se recomanda si in enuntul temei). Pentru a elibera si
>>> memoria in cazul unei erori sau a returna exact codul apelului de sistem
>>> care a generat eroarea in program, iti poti face propriul mecanism (de
>>> exemplu o functie helper, un macro DIE modificat sau un efect de tip
>>> waterfall in cazul unei erori).
>>> Ca sa avem comportament diferit in functie de platforma (de exemplu sa
>>> folosim GetLastError() pe Windows) ar trebui sa avem directive de
>>> preprocesare de forma #ifdef _WIN32, ceea ce este interzis la aceasta tema.
>>>
>>> Spor!
>>> Adrian Pop
>>>
>>> 2018-03-06 16:16 GMT+02:00 Mihai Popescu via so <so at cursuri.cs.pub.ro>:
>>>>
>>>> Bună ziua,
>>>>
>>>> Ne este spus în laboratoare și teme să folosim macro-ul DIE pentru
>>>> verificarea codului de eroare întors de un apel de sistem.
>>>> Am observat că în resurse [1], [2] este implementat apelând
>>>> exit(EXIT_FAILURE). Acest lucru face ca procesul să intoarcă de fiecare dată
>>>> 1, nu codul de eroare întors de un apel de sistem, deoarece EXIT_FAILURE
>>>> este definit astfel în stdlib.h :
>>>> #define EXIT_FAILURE 1 /* Failing exit status. */
>>>>
>>>> Codul de eroare poate fi luat:
>>>> - în Linux din errno, macro definit în errno.h
>>>> - în Windows apelând GetLastError()
>>>>
>>>> Pe acesta ar trebui să îl returneze și procesul.
>>>>
>>>> [1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die
>>>> [2] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/c_tips
>>>
>>>
>>
>>
> _______________________________________________
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
More information about the so
mailing list