Функция

RemarksRemarks

Функция _cexit вызывает, в порядке «последним поatexit, первым обслужен» (ЛИФО) функции, зарегистрированные с помощью atexit и _onexit.The _cexit function calls, in last-in, first-out (LIFO) order, the functions registered by atexit and _onexit. Затем _cexit сбрасывает все буферы ввода-вывода и закрывает все открытые потоки перед возвратом.Then _cexit flushes all I/O buffers and closes all open streams before returning. _c_exit совпадает с _exit , но возвращается в вызывающий процесс без обработки atexit или _onexit или очистки буферов потока._c_exit is the same as _exit but returns to the calling process without processing atexit or _onexit or flushing stream buffers. Поведение функций Exit, _exit, _cexitи _c_exit показано в следующей таблице.The behavior of exit, _exit, _cexit, and _c_exit is shown in the following table.

При вызове функций _cexit или _c_exit деструкторы для всех временных или автоматических объектов, которые существуют во время вызова, не вызываются.When you call the _cexit or _c_exit functions, the destructors for any temporary or automatic objects that exist at the time of the call are not called. Автоматический объект — это объект, который определяется в функции, если он не объявлен статическим.An automatic object is an object that is defined in a function where the object is not declared to be static. Временный объект — это объект, созданный компилятором.A temporary object is an object created by the compiler. Чтобы уничтожить автоматический объект перед вызовом _cexit или _c_exit, явно вызовите деструктор для объекта следующим образом:To destroy an automatic object before calling _cexit or _c_exit, explicitly call the destructor for the object, as follows:

По умолчанию глобальное состояние этой функции ограничивается приложением.By default, this function’s global state is scoped to the application. Чтобы изменить это, см. раздел глобальное состояние в CRT.To change this, see Global state in the CRT.

sys.platform

Значение sys.platform – идентификатор платформы. Вы можете использовать sys.platform чтобы добавлять модули к sys.path, импортировать разные модули, в зависимости от платформы, или запускать разные части кода. Давайте взглянем:

Python

import sys
print(sys.platform) # ответ: ‘win32’

В данном примере мы видим, что Python работает в Windows. Вот пример того, как мы можем воспользоваться данной информацией:

Python

import sys

os = sys.platform
if os == «win32»:
# Работаем с реестром Windows
import _winreg
elif os.startswith(‘linux’):
# Выполняем Linux комманду
import subprocess
subprocess.Popen()

Данный код показывает способы проверки того, используем ли мы определенную операционную систему. Если мы используем Windows, мы получим определенную информацию из реестра Windows, при помощи модуля Python под названием _winreg. Если мы используем Linux, мы можем выполнить команду ls, чтобы получить информацию о каталоге, в котором мы находимся.

ЗАМЕЧАНИЯ

Нигде не определено, что должно случиться, если одна из функций,
зарегистрированных с помощью atexit(3) и on_exit(3), вызовет exit()
или longjmp(3). Заметим, что вызов execve(2) удаляет регистрацию
функций, сделанную с помощью atexit(3) и on_exit(3).

Использование EXIT_SUCCESS и EXIT_FAILURE является более переносимым
методом (в не-UNIX окружения), чем указание 0 и какого-то ненулевого
значения (например, 1 или -1). В частности, в VMS используется другое
соглашение.

В BSD пытались стандартизовать коды завершения; смотрите файл
<sysexits.h>.

После exit() код завершения должен передаваться родительскому
процессу. Есть три случая. Если родитель установил флаг SA_NOCLDWAIT или
задал обработчик SIGCHLD равным SIG_IGN, то код отбрасывается. Если
родитель ждал потомка, то ему возвращается код завершения. В обоих случаях
процесс в стадии выхода сразу завершается. Если родитель не указал, что ему
не нужен код завершения, и он не выполняет ожидание, то завершающийся
процесс превращается в «зомби» (который ничего не делает, но хранит один
байт с кодом завершения) для того, чтобы родитель мог прочитать код
завершения позднее с помощью одного из вызовов wait(2).

Если в реализации поддерживается сигнал SIGCHLD, то он посылается
родителю. Если родитель установил флаг SA_NOCLDWAIT, то поведение при
сигнале SIGCHLD не определено.

Если процесс является лидером сеанса и управляющим терминала сеанса, то
каждому процессу из группы фонового режима этого управляющего терминала
посылается сигнал SIGHUP, и терминал отключается от сеанса, чтобы его
можно было захватить новому управляющему процессу.

Если завершение процесса приводит к осиротению группы процессов, и если
любой член только что осиротевшей группы останавливается, то каждому
процессу этой группы после сигнала SIGHUP будет послан сигнал
SIGCONT. Описание процесса осиротения группы смотрите в setpgid(2).

Аргументы из файла

Argparse позволяет передавать скрипту значения аргументов из файлов. Это полезно когда а) при запуске скрипта в командную строку необходимо вводить большое количество аргументов, что неудобно, б) можно использовать как аналог конфигурационных файлов запуска скрипта с различными устойчивыми наборами параметров. Загрузка аргументов из файла выполняется так

parser = argparse.ArgumentParser(fromfile_prefix_chars='#')
parser.add_argument('-f', nargs=2)
parser.add_argument('--bar')
parser.add_argument('b')
p=parser.parse_args()
print p

При создании экземпляра парсера необходимо определить односимвольный префикс. Он будет указывать парсеру, что после этого префикса идет имя файла (а не очередной аргумент) из которого нужно получить набор аргументов для запуска скрипта.

Далее, в файле можно перечислять только те аргументы, которые добавлены в экземпляр парсера. правильно.

Правило составления файла с аргументами следующее: сначала идет псевдоним опционального аргумента (со всеми необходимыми префиксами), затем на следующей строке — его значение (если предусмотрено). Если аргумент предполагает несколько значений каждый указывается в новой строке. В остальном правила указания аргументов в файле (в том числе и их порядок) таакой же как и в командной строке.

Теперь при запуске скрипта достаточно только указать имя файла с аргументами.

Кстати ничто не мешает нам задавать аргументы параллельно в файле и командной строке. В данном случае парсер работает по следующему правилу: значение аргумента будет таким, который был задан последним. Тоесть если сначала указать имя файла с аргументами, а затем определить аргумент в командной строке, то аргументу будет присвоено значение из командной строки. И наоборот

И еще пара моментов. Описанные правила указания аргументов в файле определяются работой парсера по умолчанию. Вместе с тем argparse позволяет создать собственный парсер, задающий другие правила. Соответственно и порядок указания аргументов в файле изменится. Подробнее —

Чтобы избежать исключение парсера, вызванного тем, что в файле определены аргументы не добавленные в парсер, в скрипте можно предусмотреть проверку. Делается это при помощи метода parse_known_args(). Например так

parser = argparse.ArgumentParser(fromfile_prefix_chars='#')
parser.add_argument('-a')
parser.add_argument('-b')
p=parser.parse_known_args()
print p

Способы решения ошибки SYSTEM_EXIT_OWNED_MUTEX на Windows 10

Если на вашем компьютере появилась ошибка 0x00000039, то разработчики Microsoft рекомендуют в первую очередь обновить Windows 10, установив все обновления.

Частой причиной синего экрана смерти SYSTEM_EXIT_OWNED_MUTEX становиться повреждения драйвера видеокарты. Поэтому рекомендуем переустановить программное обеспечение для видеоадаптера. Для этого нужно перейти в Диспетчер устройств, развернуть ветку «Видеоадаптеры» и нажать на элементе правой кнопкой мыши. Далее выбираем «Обновить драйвера».

Далее выбираем «Выполнить поиск драйверов на этом компьютере», предварительно загрузив на свой ПК актуальное программное обеспечение с официальной страницы производителя комплектующего.

Также не помешает обновить все драйвера, так как сбоить может и другой драйвер. Для автоматического обновления можно выбрать программу DriverPack Solution.

Поскольку ошибку SYSTEM_EXIT_OWNED_MUTEX может вызвать повреждение системных файлов, то для их поиска и исправления нужно запустить командную строку с правами Администратора и ввести sfc /scannow.

Для поиска и исправления неполадок можно использовать штатную утилиту от Windows 10. Для её запуска потребуется открыть «Параметры», «Обновления и безопасность». В меню слева нужно выбрать «Устранение неполадок». Далее выбираем BSOD и запускаем утилиту. Следуем подсказкам, которые появляются на экране.

Также не помешает запустить в командной строке с правами Админа команду DISM, которая развернет образ Windows 10 заново, решив проблему. Для этого в консоли вводим DISM / Online / Cleanup-Image / RestoreHealth.

Если же такая команда не помогла, то её нужно повторить со среды восстановления системы. Для этого нужно подключить к ПК установочную флешку или диск, выбрать «Восстановление системы», а далее «Командную строку». В консоли по очереди вводим:

• dism /online /cleanup-image /scanhealth
• dism /online /cleanup-image /restorehealth
• DISM /Online /Cleanup-Image /RestoreHealth /source:WIM:X:SourcesInstall.wim:1 /LimitAccess – где вместо Х ставим букву диска с Windows 10.

После выполнения данных команд нужно перезагрузить систему и некоторое время потестировать ПК, чтобы понять, исчез ли BSOD.

Важно отметить, что на многих форумах часто указывается, что виновником такого синего экрана часто становиться поврежденный диск и оперативная память. Поэтому для проверки накопителя и ОЗУ рекомендуем записать на флешку такие программы, как MemTest86 и Victoria HDD

Их нужно запустить в обход Windows 10. Для этого в BIOS-е нужно выставить приоритетность загрузки с флешки и только затем запустить проверку HDD или SSD, а после модулей оперативной памяти.

Если же вышеописанные методы не помогли решить проблему, то нужно выполнить откат системы до раннего состояния или вовсе переустановить Windows 10.

Комментарии

Для параметра используйте ненулевое число, чтобы указать ошибку.For the parameter, use a non-zero number to indicate an error. В приложении можно определить собственные коды ошибок в перечислении и возвратить соответствующий код ошибки на основе сценария.In your application, you can define your own error codes in an enumeration, and return the appropriate error code based on the scenario. Например, верните значение 1, чтобы указать, что требуемый файл отсутствует, и значение 2, чтобы указать, что файл имеет неправильный формат.For example, return a value of 1 to indicate that the required file is not present, and a value of 2 to indicate that the file is in the wrong format. Список кодов выхода, используемых операционной системой Windows, см. в разделе коды системных ошибок в документации Windows.For a list of exit codes used by the Windows operating system, see System Error Codes in the Windows documentation.

Вызов Exit метода отличается от использования оператора языка программирования следующим образом:Calling the Exit method differs from using your programming language’s statement in the following ways:

• Exit всегда завершает работу приложения.Exit always terminates an application. Использование инструкции может привести к завершению работы приложения только в том случае, если оно используется в точке входа приложения, например в методе.Using the statement may terminate an application only if it is used in the application entry point, such as in the method.

• Exit немедленно завершает работу приложения, даже если другие потоки работают.Exit terminates an application immediately, even if other threads are running. Если в точке входа приложения вызывается оператор, приложение завершает работу только после завершения всех потоков переднего плана.If the statement is called in the application entry point, it causes an application to terminate only after all foreground threads have terminated.

• Exit требует, чтобы вызывающий объект имел разрешение на вызов неуправляемого кода.Exit requires the caller to have permission to call unmanaged code. Оператор не имеет значение.The statement does not.

• Если Exit вызывается из блока или , код в любом блоке не выполняется.If Exit is called from a or block, the code in any block does not execute. Если используется оператор, код в блоке выполняется.If the statement is used, the code in the block does execute.

• Если Exit вызывается, когда выполняется код в области ограниченного выполнения (CER), CER не завершит выполнение.If Exit is called when code in a constrained execution region (CER) is running, the CER will not complete execution. Если используется инструкция, CER завершает выполнение.If the statement is used, the CER completes execution.

Решение

призвание Функция не является «плохой» в том смысле, что она имеет четко определенное поведение — в этом нет ничего принципиально неправильного.

Но если вы пишете функцию, которая может оказаться в библиотеке, например, вызов отсюда — плохая практика в целом: гораздо лучше сообщить об ошибке вызывающему коду (например, с помощью определенного возвращаемого значения или исключения) и позволить вызывающему коду решить, что делать. (Есть случаи, когда это совершенно верно, например, если вы пишете функцию с именем Ну, ваши пользователи ожидают прекращения.)

В вашем случае ваша функция синтаксического анализа, вероятно, не должна вызывать : вы, возможно, захотите, например, в какой-то момент в будущем, ваш основной код будет запрашивать у пользователя другое имя файла, если анализ первого не удался. Если ваша процедура синтаксического анализа завершает работу программы, вы должны изменить как основной код, так и эту функцию. Если бы он сигнализировал об ошибке, вам нужно всего лишь изменить логику в ,

(И не только без вывода сообщения об ошибке или регистрации чего-либо подобного тому, что вы делаете выше, это поможет разочарованным пользователям, которые не могут знать, как исправить проблему, с которой столкнулся код.)

15

Семантические ошибки

Семантическая (или «смысловая») ошибка возникает, когда код синтаксически правильный, но выполняет не то, что нужно программисту. Например:

for (int count=0; count <= 4; ++count)
std::cout << count << » «;

Возможно, программист хотел, чтобы вывелось , но на самом деле выведется .

Семантические ошибки не улавливаются компилятором и могут иметь разное влияние: некоторые могут вообще не отображаться, что приведет к неверным результатам, к повреждению данных или вообще к сбою программы. Поэтому об семантических ошибках беспокоиться уже придется.

Они могут возникать несколькими способами. Одной из наиболее распространенных семантических ошибок является логическая ошибка. Логическая ошибка возникает, когда программист неправильно программирует логику выполнения кода. Например, вышеприведенный фрагмент кода имеет логическую ошибку. Вот еще один пример:

if (x >= 4)
std::cout << «x is greater than 4»;

Что произойдет, если будет равен ? Условие выполнится как , а программа выведет . Логические ошибки иногда бывает довольно-таки трудно обнаружить.

Другой распространенной семантической ошибкой является ложное предположение. Ложное предположение возникает, когда программист предполагает, что что-то будет истинным или ложным, а оказывается наоборот. Например:

std::string hello = «Hello, world!»;
std::cout << «Enter an index: «;

int index;
std::cin >> index;

std::cout << «Letter #» << index << » is » << hello << std::endl;

Заметили потенциальную проблему здесь? Предполагается, что пользователь введет значение между и длиной строки . Если же пользователь введет отрицательное число или число побольше, то окажется за пределами диапазона массива. В этом случае, поскольку мы просто выводим значение по индексу, результатом будет вывод мусора (при условии, что пользователь введет число вне диапазона). Но в других случаях ложное предположение может привести и к изменениям значений переменных, и к сбою в программе.

Безопасное программирование — это методика разработки программ, которая включает анализ областей, где могут быть допущены ложные предположения, и написание кода, который обнаруживает и обрабатывает любой случай такого нарушения, чтобы свести к минимуму риск возникновения сбоя или повреждения программы.

ОПИСАНИЕ

exitstatus & 0377wait

Вызываются все функции, зарегистрированные с помощью atexit(3) и
on_exit(3), в обратном по отношению к регистрации порядке (в этих
функциях возможно использовать atexit(3) или on_exit(3) для
регистрации дополнительной функции, которая будет также вызвана при выходе;
при этом она добавляется в начало списка функций, которые осталось
вызвать). Если из одной из функций не происходит возврат (например, она
вызывает _exit(2) или завершает себя по сигналу), то оставшиеся функции
не вызываются, и дальнейший процесс выхода прекращается (в частности, запись
потоков stdio(3)). Если функция зарегистрирована с помощью atexit(3)
или on_exit(3) несколько раз, то она вызывается столько раз, сколько
зарегистрирована.

Все открытые потоки stdio(3) записываются и закрываются. Файлы, созданные
tmpfile(3), удаляются.

Признаки ошибок SYSTEM_EXIT_OWNED_MUTEX типа «синий экран»

• Появляется ошибка “SYSTEM_EXIT_OWNED_MUTEX” и окно активной программы вылетает.
• Отображается сообщение «STOP Ошибка 0x39: SYSTEM_EXIT_OWNED_MUTEX».
• «Была обнаружена проблема, и Windows была выгружена, чтобы предотвратить повреждения компьютера. Очевидно, проблема вызвана следующим файлом»
• Ваш компьютер часто прекращает работу после отображения ошибки 0x39 при запуске определенной программы.
• Отображается сообщение “The SYSTEM_EXIT_OWNED_MUTEX bug check has a value of 0x00000039. This indicates that the worker routine returned without releasing the mutex object that it owned.”.
• Windows медленно работает и медленно реагирует на ввод с мыши или клавиатуры.
• Компьютер периодически «зависает» на несколько секунд.

В большинстве случаев вы сталкиваетесь в ошибками типа «синий экран» SYSTEM_EXIT_OWNED_MUTEX после установки нового аппаратного или программного обеспечения. Синие экраны SYSTEM_EXIT_OWNED_MUTEX могут появляться при установке программы, если запущена программа, связанная с SYSTEM_EXIT_OWNED_MUTEX (например, Windows Operating System), когда загружается драйвер Microsoft Corporation или во время запуска или завершения работы Windows

Отслеживание момента появления ошибки ОСТАНОВКИ является важной информацией при устранении проблемы

NOTES top

       The behavior is undefined if one of the functions registered using
       atexit(3) and on_exit(3) calls either exit() or longjmp(3).  Note
       that a call to execve(2) removes registrations created using
       atexit(3) and on_exit(3).

       The use of EXIT_SUCCESS and EXIT_FAILURE is slightly more portable
       (to non-UNIX environments) than the use of 0 and some nonzero value
       like 1 or -1.  In particular, VMS uses a different convention.

       BSD has attempted to standardize exit codes (which some C libraries
       such as the GNU C library have also adopted); see the file
       <sysexits.h>.

       After exit(), the exit status must be transmitted to the parent
       process.  There are three cases:

       ·  If the parent has set SA_NOCLDWAIT, or has set the SIGCHLD handler
          to SIG_IGN, the status is discarded and the child dies
          immediately.

       ·  If the parent was waiting on the child, it is notified of the exit
          status and the child dies immediately.

       ·  Otherwise, the child becomes a "zombie" process: most of the
          process resources are recycled, but a slot containing minimal
          information about the child process (termination status, resource
          usage statistics) is retained in process table.  This allows the
          parent to subsequently use waitpid(2) (or similar) to learn the
          termination status of the child; at that point the zombie process
          slot is released.

       If the implementation supports the SIGCHLD signal, this signal is
       sent to the parent.  If the parent has set SA_NOCLDWAIT, it is
       undefined whether a SIGCHLD signal is sent.

   Signals sent to other processes
       If the exiting process is a session leader and its controlling
       terminal is the controlling terminal of the session, then each
       process in the foreground process group of this controlling terminal
       is sent a SIGHUP signal, and the terminal is disassociated from this
       session, allowing it to be acquired by a new controlling process.

       If the exit of the process causes a process group to become orphaned,
       and if any member of the newly orphaned process group is stopped,
       then a SIGHUP signal followed by a SIGCONT signal will be sent to
       each process in this process group.  See setpgid(2) for an
       explanation of orphaned process groups.

       Except in the above cases, where the signalled processes may be
       children of the terminating process, termination of a process does
       not in general cause a signal to be sent to children of that process.
       However, a process can use the prctl(2) PR_SET_PDEATHSIG operation to
       arrange that it receives a signal if its parent terminates.

DESCRIPTION top

       The exit() function causes normal process termination and the least
       significant byte of status (i.e., status & 0xFF) is returned to the
       parent (see wait(2)).

       All functions registered with atexit(3) and on_exit(3) are called, in
       the reverse order of their registration.  (It is possible for one of
       these functions to use atexit(3) or on_exit(3) to register an
       additional function to be executed during exit processing; the new
       registration is added to the front of the list of functions that
       remain to be called.)  If one of these functions does not return
       (e.g., it calls _exit(2), or kills itself with a signal), then none
       of the remaining functions is called, and further exit processing (in
       particular, flushing of stdio(3) streams) is abandoned.  If a
       function has been registered multiple times using atexit(3) or
       on_exit(3), then it is called as many times as it was registered.

       All open stdio(3) streams are flushed and closed.  Files created by
       tmpfile(3) are removed.

       The C standard specifies two constants, EXIT_SUCCESS and
       EXIT_FAILURE, that may be passed to exit() to indicate successful or
       unsuccessful termination, respectively.

Remarks

The exit, _Exit and _exit functions terminate the calling process. The exit function calls destructors for thread-local objects, then calls—in last-in-first-out (LIFO) order—the functions that are registered by atexit and _onexit, and then flushes all file buffers before it terminates the process. The _Exit and _exit functions terminate the process without destroying thread-local objects or processing atexit or _onexit functions, and without flushing stream buffers.

Although the exit, _Exit and _exit calls do not return a value, the value in status is made available to the host environment or waiting calling process, if one exists, after the process exits. Typically, the caller sets the status value to 0 to indicate a normal exit, or to some other value to indicate an error. The status value is available to the operating-system batch command ERRORLEVEL and is represented by one of two constants: EXIT_SUCCESS, which represents a value of 0, or EXIT_FAILURE, which represents a value of 1.

The exit, _Exit, _exit, quick_exit, _cexit, and _c_exit functions behave as follows.

When you call the exit, _Exit or _exit function, the destructors for any temporary or automatic objects that exist at the time of the call are not called. An automatic object is a non-static local object defined in a function. A temporary object is an object that’s created by the compiler, such as a value returned by a function call. To destroy an automatic object before you call exit, _Exit, or _exit, explicitly call the destructor for the object, as shown here:

Do not use DLL_PROCESS_ATTACH to call exit from DllMain. To exit the DLLMain function, return FALSE from DLL_PROCESS_ATTACH.

By default, this function’s global state is scoped to the application. To change this, see Global state in the CRT.

Решение

Это два имени для одной и той же функции, которая выполняет одни и те же функции.

Обратите внимание, однако, что в C ++ / (независимо от того, как вы получите его имя) действительно имеет некоторое поведение, которое не указано для в библиотеке C. Особенно,

1. сначала уничтожает все объекты с продолжительностью хранения потока, которые связаны с текущим потоком.
2. Объекты со статической продолжительностью хранения уничтожаются, а любые функции, зарегистрированные с вызваны.
3. После этого мы получаем нормальное поведение C:
   • Открытые потоки C сбрасываются, если у них есть неписанные данные, то они закрываются.
   • Файлы, созданные с помощью вызова удалены.
   • Элемент управления возвращается в среду хоста, возвращая успех или неудачу в зависимости от значения, переданного в вызове ( или же => успех, => ошибка, все остальное определяется реализацией).

Обратите внимание, в частности, что локальные объекты не уничтожен любым призывом к выходу. Это означает, что вы действительно должны забыть все вышеперечисленное и просто никогда вызов / из кода C ++

Хотя комитет, по-видимому, считает, что совместимость с кодом C является достаточно сильной мотивацией, чтобы они необходимость чтобы оставить это в стандарте, вам, конечно, не нужно его использовать — и почти при любых достаточно нормальных обстоятельствах вы не должны. Уничтожение локальных объектов при выходе из области видимости — достаточно важная часть C ++, такая функция, как что устраняет эту гарантию, приводит к почти ничего, кроме головной боли

Это означает, что вы действительно должны забыть все вышеперечисленное и просто никогда вызов / из кода C ++. Хотя комитет, по-видимому, считает, что совместимость с кодом C является достаточно сильной мотивацией, чтобы они необходимость чтобы оставить это в стандарте, вам, конечно, не нужно его использовать — и почти при любых достаточно нормальных обстоятельствах вы не должны. Уничтожение локальных объектов при выходе из области видимости — достаточно важная часть C ++, такая функция, как что устраняет эту гарантию, приводит к почти ничего, кроме головной боли.

Если вам нужно поведение, похожее на поведение вы обычно хотите сделать что-то вроде этого:

Затем в остальной части кода, где вы бы иначе вызвали , ты вместо , Таким образом, все локальные переменные будут уничтожены (т.е. произойдет разматывание стека) и затем вы будете делать нормальный выход в окружающую среду.

8

COLOPHON top

       This page is part of release 5.08 of the Linux man-pages project.  A
       description of the project, information about reporting bugs, and the
       latest version of this page, can be found at
       https://www.kernel.org/doc/man-pages/.

Linux                            2020-02-09                          EXIT(3)

Pages that refer to this page:
man(1), 
exit(2), 
_exit(2), 
_Exit(2), 
kill(2), 
vfork(2), 
wait(2), 
waitid(2), 
waitpid(2), 
abort(3), 
assert(3), 
assert_perror(3), 
atexit(3), 
err(3), 
error(3), 
error_at_line(3), 
error_message_count(3), 
error_one_per_line(3), 
error_print_progname(3), 
errx(3), 
longjmp(3), 
on_exit(3), 
pthread_create(3), 
pthread_detach(3), 
pthread_exit(3), 
sd_bus_get_exit_on_disconnect(3), 
sd_bus_set_exit_on_disconnect(3), 
setjmp(3), 
siglongjmp(3), 
sigsetjmp(3), 
stderr(3), 
stdin(3), 
stdio(3), 
stdout(3), 
tmpfile(3), 
verr(3), 
verrx(3), 
vwarn(3), 
vwarnx(3), 
warn(3), 
warnx(3)