Чи слід використовувати exit () у C?

Є питання щодо використання exitв C ++. Відповідь обговорює, що це не є гарною ідеєю в основному через RAII, наприклад, якщо exitдесь викликається код, деструктори об'єктів не будуть викликані, отже, якщо, наприклад, деструктор мав на меті записати дані у файл, цього не трапиться , оскільки деструктор не викликався.

Мене цікавило, як склалася ця ситуація в C. Чи застосовуються подібні проблеми і в C? Я думав, оскільки в C ми не використовуємо конструктори / деструктори, ситуація може бути іншою в C. Так чи можна використовувати exitв C?

Я бачив такі функції, як нижче, які я вважаю чудовими для використання в деяких випадках, але цікавився, чи маємо подібні проблеми в C з використанням exit, як описано вище у C ++? (що може призвести до використання таких функцій, як нижче, не дуже вдалою ідеєю.).

void die(const char *message)
{
    if(errno) {
        perror(message);
    } else {
        printf("ERROR: %s\n", message);
    }

    exit(1);
}

Замість того abort(), то exit()функція в С вважається «витонченим» вихід.

З C11 (N1570) 7.22.4.4/p2 Функція виходу (наголос мій):

exitФункція викликає нормальне завершення програми статися.

Стандарт також говорить у 7.22.4.4/p4, що:

Далі всі відкриті потоки з неписаними буферними даними очищаються , усі відкриті потоки закриваються , а всі файли, створені tmpfileфункцією, видаляються.

Також варто подивитися файли 7.21.3 / p5 :

Якщо mainфункція повертається до початкового абонента або якщо exit функцію викликано, всі відкриті файли закриваються (отже, всі вихідні потоки очищаються) перед завершенням програми. Інші шляхи до завершення програми, такі як виклик abortфункції, не повинні закривати всі файли належним чином.

Однак, як зазначено в коментарях нижче, ви не можете припустити, що він охоплюватиме всі інші ресурси , тому вам, можливо, доведеться вдатися до atexit()визначення зворотних викликів для їх випуску окремо. Насправді це саме те, що atexit()передбачається зробити, як сказано в 7.22.4.2/p2 Функція atexit :

У atexitрегістри функції функція , на яку вказує func, щоб бути викликана без аргументів при нормальному завершенні програми.

Примітно, що стандарт C не говорить точно, що має статися з об’єктами, що мають визначену тривалість зберігання (тобто malloc()), таким чином вимагаючи, щоб ви були в курсі того, як це робиться при певній реалізації. Для сучасної ОС, орієнтованої на хост, цілком ймовірно, що система подбає про це, але все ж ви можете вирішити це самостійно, щоб заглушити налагоджувачі пам'яті, такі як Valgrind .

Так, це нормально використовувати exitв C.

Для забезпечення всіх буферів та витонченого впорядкованого вимкнення рекомендується використовувати цю функцію atexit, більше інформації про це тут

Приклад коду буде таким:

void cleanup(void){
   /* example of closing file pointer and free up memory */
   if (fp) fclose(fp);
   if (ptr) free(ptr);
}

int main(int argc, char **argv){
   /* ... */
   atexit(cleanup);
   /* ... */
   return 0;
}

Тепер, коли б exitне було викликано, функція cleanupбуде виконана, що може забезпечити витончене вимкнення, очищення буферів, пам'яті тощо.

У вас немає конструкторів і деструкторів, але у вас можуть бути ресурси (наприклад, файли, потоки, сокети), і важливо правильно їх закрити. Буфер не може бути записаний синхронно, тому вихід із програми без попереднього правильного закриття ресурсу може призвести до пошкодження.

Використання exit()- це нормально

Два основні аспекти дизайну коду, про які ще не згадувалося, - це «потоки» та «бібліотеки».

У однопотоковій програмі в коді, який ви пишете для реалізації цієї програми, використання exit()чудово. Мої програми використовують це регулярно, коли щось пішло не так, і код не збирається відновити.

Але ...

Однак дзвінок exit()- це одностороння дія, яку не можна скасувати. Ось чому і „потокові роботи”, і „бібліотеки” вимагають ретельного продумування.

Різьбові програми

Якщо програма багатопотокова, то використання exit()- це драматична дія, яка завершує всі потоки. Можливо, недоречно вийти з усієї програми. Може бути доречним вийти з потоку, повідомивши про помилку. Якщо ви добре знаєте дизайн програми, можливо, такий односторонній вихід допустимий, але загалом він не буде прийнятним.

Бібліотечний код

І це застереження "про пізнання дизайну програми" стосується і коду в бібліотеках. Дуже рідко правильно викликати функцію бібліотеки загального призначення exit(). Ви б з розумом засмутилися, якщо одна зі стандартних функцій бібліотеки C не змогла повернутися лише через помилку. (Очевидно, що функції , як exit(), _Exit(), quick_exit(), abort()призначені не для повернення, то по - іншому.) Функції в бібліотеці C , отже , або «не може не» або повернути індикацію помилки так чи інакше. Якщо ви пишете код для переходу в загальну бібліотеку, вам слід уважно розглянути стратегію обробки помилок для вашого коду. Він повинен відповідати стратегіям обробки помилок програм, з якими він призначений, або обробку помилок можна зробити налаштованою.

У мене є низка бібліотечних функцій (у пакеті із заголовком "stderr.h", ім'я якого наступає на тонкий лід), які призначені для виходу, оскільки вони використовуються для повідомлення про помилки. Ці функції виходять за задумом. У цьому ж пакеті є пов’язана серія функцій, які повідомляють про помилки та не виходять із них. Вихідні функції реалізовані з точки зору функцій, які не виходять, звичайно, але це внутрішня деталь реалізації.

У мене є багато інших функцій бібліотеки, і багато з них покладаються на "stderr.h"код для повідомлення про помилки. Це дизайнерське рішення, яке я прийняв і з яким я в порядку. Але коли про помилки повідомляється про вихід функцій, це обмежує загальну корисність коду бібліотеки. Якщо код викликає функції звітування про помилки, які не закриваються, то основні шляхи коду у функції повинні мати здоровий спосіб вирішення проблем із поверненням помилок - виявити їх і передати індикацію помилки на код, що викликає.

Код для мого звіту про помилки доступний у моєму сховищі SOQ (Stack Overflow questions) на GitHub як файли stderr.cта stderr.hу підкаталозі src / libsoq .

Однією з причин, яких слід уникати exitв інших функціях, main()є можливість вилучення вашого коду з контексту. Пам'ятайте, вихід - це тип нелокального потоку управління . Як невловимі винятки.

Наприклад, ви можете написати деякі функції управління сховищем, які виходять із критичної помилки на диску. Тоді хтось вирішує перенести їх у бібліотеку. Вихід з бібліотеки - це те, що призведе до виходу програми, що викликає, у непостійному стані, до якого вона, можливо, не готова.

Або ви можете запустити його на вбудованій системі. Там нікуди вийти , щоб , все це біжить в while(1)петлі main(). Він може навіть не бути визначений у стандартній бібліотеці.

Залежно від того, що ви робите, вихід може бути найбільш логічним виходом із програми в C. Я знаю, що це дуже корисно для перевірки, щоб переконатися, що ланцюжки зворотних викликів працюють правильно. Візьмемо цей приклад зворотного виклику, який я використовував нещодавно:

unsigned char cbShowDataThenExit( unsigned char *data, unsigned short dataSz,unsigned char status)
{

    printf("cbShowDataThenExit with status %X (dataSz %d)\n", status, dataSz);
    printf("status:%d\n",status);
    printArray(data,dataSz);
    cleanUp();
    exit(0);
}

У головному циклі я налаштував все для цієї системи, а потім зачекав (1). Замість цього можна зробити глобальний прапор для виходу з циклу while, але це просто і робить те, що йому потрібно зробити. Якщо ви маєте справу з будь-якими відкритими буферами, такими як файли та пристрої, вам слід очистити їх перед закриттям для постійності.

У великому проекті страшно, коли будь-який код може вийти, крім coredump. Трасування дуже важливе для обслуговування Інтернет-сервера.