[so] [Macro-ul DIE]

Mihai Popescu mh.popescu12 at gmail.com
Tue Mar 6 17:30:04 EET 2018


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, 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
>>
>>
>
>


More information about the so mailing list