View Source

*asynchronous-safe* \[[GNU Pth|AA. C References#GNU Pth]\]
A function is "async-safe" if it can called safely and without side effects from within a signal handler context. That is, it must be able to be interrupted at any point and run linearly out of sequence without causing an inconsistent state. Very few functions are asynchronous-safe. Some asynchronous-safe operations are listed below. If a function does anything not on the list, it is probably not asynchronous-safe:

call the signal() function to reinstall a signal handler
unconditionally modify a volatile sig_atomic_t variable (as modification to this type is atomic)
call the _Exit() function to immediately terminate program execution
use a function from the extremely small subset of library functions listed in your signal() documentation as async-safe

This is sometimes referred to as 'asynchronous-signal safe'.

*free-standing environment* \[[Banahan 03|AA. C References#Banahan 03]\]
An environment without the C standard libraries. Common for stand-alone programs, such as operating systems or firmware.

*hosted environment* \[[Banahan 03|AA. C References#Banahan 03]\]
An environment that supplies the C standard libraries.

*implementation* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment.

*implementation-defined behavior* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Unspecified behavior where each implementation documents how the choice is made.

*locale-specific behavior* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Behavior that depends on local conventions of nationality, culture, and language that each implementation documents.

*reentrant* \[[Dowd 06|AA. C References#Dowd 06]\]
A function is reentrant if multiple instances of the same function can run in the same address space concurrently without creating the potential for inconsistent states.

*undefined behavior* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which the standard imposes no requirements.  An example of undefined behavior is the behavior on integer overflow.

*unspecified behavior* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Behavior where the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance.

*validation* \[[IEC 61508-4|AA. C References#IEC 61508-4]\]
Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled.

*verification* \[[IEC 61508-4|AA. C References#IEC 61508-4]\]
Confirmation by examination and provision of objective evidence that the requirements have been fulfilled.