asynchronous-safe [[GNU Pth]]
A function is asynchronous-safe, or asynchronous-signal safe, if it can be 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. Some asynchronous-safe operations are listed below:
- call the
signal()function to reinstall a signal handler - unconditionally modify a
volatile sig_atomic_tvariable (as modification to this type is atomic) - call the
_Exit()function to immediately terminate program execution - invoke an asynchronous-safe function, as specified by your implementation
Very few functions are asynchronous-safe. If a function performs any other operations, it is probably not asynchronous-safe.
freestanding environment [[ISO/IEC 9899-1999]]
An environment in which C program execution may take place without any benefit of an operating system. Program startup might occur at some function other than main(), complex types might not be implemented, and only certain minimal library facilities are guaranteed to be available.
hosted environment [[ISO/IEC 9899-1999]]
An environment that is not freestanding. Program startup occurs at main(), complex types are implemented, and all C standard library facilities are available.
implementation [[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]]
Unspecified behavior where each implementation documents how the choice is made.
locale-specific behavior [[ISO/IEC 9899-1999]]
Behavior that depends on local conventions of nationality, culture, and language that each implementation documents.
reentrant [[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]]
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]]
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]]
Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled.
verification [[IEC 61508-4]]
Confirmation by examination and provision of objective evidence that the requirements have been fulfilled.