Anchor |
---|
| abnormal termination |
---|
| abnormal termination |
---|
|
abnormal termination [Open Group 2008] Abnormal termination occurs when requested by the
abort()
function or when some signals are received. See also
#normal termination.
unmigratedwikimarkup<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e955238a-f0a9-437d-8474-1ed7be340033"><ac:parameter ac:name=""> async-signal-safe</ac:parameter></ac:structured-macro>
*async-signal-safe function* \[[ISO/IEC 9945:2008|AA. Bibliography#ISO/IEC 9945-2008]\]
A function that may be invoked, without restriction, from signal-catching functions. No function \[defined in ISO/IEC 9945\] is safe function [ISO/IEC 9945:2008] A function that may be invoked, without restriction, from signal-catching functions. No function [defined in ISO/IEC 9945] is async-signal-safe unless explicitly described as such. See also [#asynchronous-safe]. Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e9a29067-6b34-4413-acee-472927098009"><ac:parameter ac:name=""> asynchronous-safe</ac:parameter></ac:structured-macro>
*asynchronous-safe function* \[[GNU Pth|AA. Bibliography#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 to run linearly out of sequence without causing an inconsistent state. It must also function properly when global data might itself be in an inconsistent state. Some asynchronous-safe operations are listed here: |
- 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 - invoke an asynchronous-safe function, as specified by your implementation
Few functions are portably asynchronous-safe. If a function performs any other operations, it is probably not portably asynchronous-safe.
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="32b5ed2c-2adb-42dd-a403-3821592bcef0"><ac:parameter ac:name=""> availability</ac:parameter></ac:structured-macro>
*availability* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
The degree to which a system or component is operational and accessible when required for use. Often expressed as a probability. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="01394f05-070b-48b8-a9d6-ae633b3e7d7a"><ac:parameter ac:name=""> conforming program</ac:parameter></ac:structured-macro>
*conforming* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Conforming programs may depend on nonportable features of a conforming implementation. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="01ebfe48-89d1-4f20-97fa-3b6ead94e1e0"><ac:parameter ac:name=""> data race</ac:parameter></ac:structured-macro>
*data race* \[ISO/IEC Document Number N3000 -- Working Draft, Standard for Programming Language C++, November 2009\]
The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. |
...
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="3b1c3763-27f4-4276-9f3b-4ffb447055fa"><ac:parameter ac:name=""> error tolerance</ac:parameter></ac:structured-macro>
*error tolerance* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
The ability of a system or component to continue normal operation despite the presence of erroneous inputs. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="a3a99b1d-6380-4fda-aa9e-05d2f77a65e4"><ac:parameter ac:name=""> exploit</ac:parameter></ac:structured-macro>
*exploit* \[[Seacord 2005a|AA. Bibliography#Seacord 05]\]
A piece of software or a technique that takes advantage of a security vulnerability to violate an explicit or implicit [security policy|BB. Definitions#security policy]. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="f9ece24f-507e-4635-a8dc-b4d70b59ed4a"><ac:parameter ac:name=""> fail safe</ac:parameter></ac:structured-macro>
*fail safe* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
Pertaining to a system or component that automatically places itself in a safe operating mode in the event of a failure; for example, a traffic light that reverts to blinking red in all directions when normal operation fails. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="588e7663-0dbd-421f-8aa9-5b0844d808d6"><ac:parameter ac:name=""> fail soft</ac:parameter></ac:structured-macro>
*fail soft* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
Pertaining to a system or component that continues to provide partial operational capability in the event of certain failures; for example, a traffic light that continues to alternate between red and green if the yellow light fails. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="af0f3236-a769-4080-aeb1-fbb9a68fa9a8"><ac:parameter ac:name=""> fault tolerance</ac:parameter></ac:structured-macro>
*fault tolerance* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
The ability of a system or component to continue normal operation despite the presence of hardware or software faults. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="a1cc99b0-43c8-41ed-8067-86f85512a035"><ac:parameter ac:name=""> freestanding environment</ac:parameter></ac:structured-macro>
*freestanding environment* \[[ISO/IEC 9899-1999|AA. Bibliography#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. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="9a1f8a7c-deec-4993-a5cc-8106569e9a0c"><ac:parameter ac:name=""> function-like macro</ac:parameter></ac:structured-macro>
*function-like macro* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
A {{#define}} preprocessing directive that defines an identifier immediately followed by zero or more parameters, the ellipsis ({{...}}), or a combination of the two, enclosed in parentheses, similar syntactically to a function call. Subsequent instances of the macro name followed by a parenthesized list of arguments in a translation unit are replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive. See also [#object-like macro] and [#unsafe function-like macro]. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="7cc5be20-1e26-4d36-ace0-ffc35941021c"><ac:parameter ac:name=""> hosted environment</ac:parameter></ac:structured-macro>
*hosted environment* \[[ISO/IEC 9899-1999|AA. Bibliography#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. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="cb6155a0-be8b-4b9e-a3a8-3f9112b9daf1"><ac:parameter ac:name=""> implementation</ac:parameter></ac:structured-macro>
*implementation* \[[ISO/IEC 9899-1999|AA. Bibliography#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. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="8fc5b108-f9a0-4e8f-9e32-155299b30195"><ac:parameter ac:name=""> implementation-defined behavior</ac:parameter></ac:structured-macro>
*implementation-defined behavior* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Unspecified behavior whereby each implementation documents how the choice is made. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="2ec223ec-f409-406e-bbb0-bb114cff9add"><ac:parameter ac:name=""> incomplete type</ac:parameter></ac:structured-macro>
*incomplete type* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
A type that describes an identifier but lacks information needed to determine the size of the identifier. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e4042eb6-ed23-4fd1-9eaf-03b9c50e3009"><ac:parameter ac:name=""> indeterminate value</ac:parameter></ac:structured-macro>
*indeterminate value* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Either an [#unspecified value] or a [#trap representation]. |
...
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="991922e2-d57d-4480-8418-7da3b68e6d00"><ac:parameter ac:name=""> locale-specific behavior</ac:parameter></ac:structured-macro>
*locale-specific behavior* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Behavior that depends on local conventions of nationality, culture, and language that each implementation documents. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="1bce5f21-e563-42a0-82ed-a4e106aba0f5"><ac:parameter ac:name=""> lvalue</ac:parameter></ac:structured-macro>
*lvalue* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
An expression with an object type or an incomplete type other than {{void}}. The name _lvalue_ comes originally from the assignment expression {{E1 = E2}}, in which the left operand {{E1}} is required to be a (modifiable) lvalue. It is perhaps better considered as representing an object "locator value". |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="31b737b7-6be9-4921-811e-4801c7ba3f40"><ac:parameter ac:name=""> mitigation</ac:parameter></ac:structured-macro>
*mitigation* \[[Seacord 2005a|AA. Bibliography#Seacord 05]\]
Methods, techniques, processes, tools, or runtime libraries that can prevent or limit exploits against vulnerabilities. |
...
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="85b130b0-5dc4-4741-9fe3-13ec950c94ab"><ac:parameter ac:name=""> object-like macro</ac:parameter></ac:structured-macro>
*object-like macro* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
A {{#define}} preprocessing directive that defines an identifier with no parentheses. Subsequent instances of the macro name in a translation unit are replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive. See also [#function-like macro]. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="83c8eaf5-f135-4ccd-ba72-ff2a1134760a"><ac:parameter ac:name=""> reentrant</ac:parameter></ac:structured-macro>
*reentrant* \[[Dowd 2006|AA. Bibliography#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. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="4977c622-bf81-4da4-a2a1-e032862a0bf4"><ac:parameter ac:name=""> reliability</ac:parameter></ac:structured-macro>
*reliability* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
The ability of a system or component to perform its required functions under stated conditions for a specified period of time. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e44ee5d8-d57d-4813-b913-bc2ccfb6cbd3"><ac:parameter ac:name=""> robustness</ac:parameter></ac:structured-macro>
*robustness* \[[IEEE Std 610.12 1990|AA. Bibliography#IEEE Std 610.12 1990]\]
The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="8f7d70a7-6c54-4225-aa02-55cbf74646e1"><ac:parameter ac:name=""> rvalue</ac:parameter></ac:structured-macro>
*rvalue* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Value of an expression. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="7319c1c2-d869-4939-8fe7-2d195690ebb6"><ac:parameter ac:name=""> security flaw</ac:parameter></ac:structured-macro>
*security flaw* \[[Seacord 2005a|AA. Bibliography#Seacord 05]\]
A software defect that poses a potential security risk. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="ad3e18e4-e4a5-4abe-8afa-3e60c714caf1"><ac:parameter ac:name=""> security policy</ac:parameter></ac:structured-macro>
*security policy* \[[Internet Society 2000|AA. Bibliography#Internet Society 00]\]
A set of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical system resources. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="4884eb58-654c-4f63-8409-9ddb0c53833e"><ac:parameter ac:name=""> sequence point</ac:parameter></ac:structured-macro>
*sequence point* C99 \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Evaluation of an expression may produce [#side effects]. At specific points in the execution sequence called _sequence points_, all side effects of previous evaluations have completed, and no side effects of subsequent evaluations have yet taken place. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e7446d4b-1293-4f1f-9fed-2eb6d1fdc6ba"><ac:parameter ac:name=""> side effect</ac:parameter></ac:structured-macro><ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="1aad4137-6da0-43bc-a8d8-de4d0c801c2e"><ac:parameter ac:name=""> side effects</ac:parameter></ac:structured-macro>
*side effect* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Changes in the state of the execution environment achieved by accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations.
Note: The IEC 60559 standard for binary floating-point arithmetic requires certain user-accessible status flags and control modes. Floating-point operations implicitly set the status flags; modes affect result values of floating-point operations. Implementations that support such floating-point state are required to regard changes to it as side effects. These are detailed in Annex F of the C Standard. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="36d41050-b2a2-4039-afe5-cabfdf01694f"><ac:parameter ac:name=""> strictly conforming</ac:parameter></ac:structured-macro>
*strictly conforming* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
A strictly conforming program is one that uses only those features of the language and library specified in the international standard. Strictly conforming programs are intended to be maximally portable among conforming implementations and can't, for example, depend on implementation-defined behavior. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="0958632d-f314-4921-bd00-15857805b6b9"><ac:parameter ac:name="">trap representation</ac:parameter></ac:structured-macro>
*trap representation* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Object representation that does not represent a value of the object type. Attempting to read the value of an object that has a trap representation other than by an expression that has a character type is [undefined | #undefined behavior]. Producing such a representation by a [#side effect] that modifies all or any part of the object other than by an expression that has a character type is undefined. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="d483a9d0-af46-483f-9a5e-c91adc5961bf"><ac:parameter ac:name=""> undefined behavior</ac:parameter></ac:structured-macro>
*undefined behavior* \[[ISO/IEC 9899-1999|AA. Bibliography#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. |
...
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="614be727-2b03-4a66-886b-ae550fc09918"><ac:parameter ac:name=""> unspecified behavior</ac:parameter></ac:structured-macro>
*unspecified behavior* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
Behavior for which the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="611c864b-e007-4db0-98e6-9168df7be53b"><ac:parameter ac:name=""> unspecified value</ac:parameter></ac:structured-macro>
*unspecified value* \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\]
A valid value of the relevant type where the C Standard imposes no requirements on which value is chosen in any instance. An unspecified value cannot be a [#trap representation]. |
...
Anchor |
---|
| asynchronous-safe |
---|
| asynchronous-safe |
---|
|
asynchronous-safe function [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 to run linearly out of sequence without causing an inconsistent state. It must also function properly when global data might itself be in an inconsistent state. Some asynchronous-safe operations are listed here:- 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 - invoke an asynchronous-safe function, as specified by your implementation
Few functions are portably asynchronous-safe. If a function performs any other operations, it is probably not portably asynchronous-safe.
Anchor |
---|
| availability |
---|
| availability |
---|
|
availability [IEEE Std 610.12 1990] The degree to which a system or component is operational and accessible when required for use. Often expressed as a probability. Anchor |
---|
| conforming program |
---|
| conforming program |
---|
|
conforming [ISO/IEC 9899-1999] Conforming programs may depend on nonportable features of a conforming implementation. data race [ISO/IEC Document Number N3000 – Working Draft, Standard for Programming Language C++, November 2009] The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. Anchor |
---|
| denial-of-service |
---|
| denial-of-service |
---|
|
denial-of-service attack Also DoS attack. An attempt to make a computer resource unavailable to its intended users. Anchor |
---|
| error tolerance |
---|
| error tolerance |
---|
|
error tolerance [IEEE Std 610.12 1990] The ability of a system or component to continue normal operation despite the presence of erroneous inputs. exploit [Seacord 2005a] A piece of software or a technique that takes advantage of a security vulnerability to violate an explicit or implicit security policy. fail safe [IEEE Std 610.12 1990] Pertaining to a system or component that automatically places itself in a safe operating mode in the event of a failure; for example, a traffic light that reverts to blinking red in all directions when normal operation fails. fail soft [IEEE Std 610.12 1990] Pertaining to a system or component that continues to provide partial operational capability in the event of certain failures; for example, a traffic light that continues to alternate between red and green if the yellow light fails. Anchor |
---|
| fault tolerance |
---|
| fault tolerance |
---|
|
fault tolerance [IEEE Std 610.12 1990] The ability of a system or component to continue normal operation despite the presence of hardware or software faults. Anchor |
---|
| freestanding environment |
---|
| freestanding environment |
---|
|
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. Anchor |
---|
| function-like macro |
---|
| function-like macro |
---|
|
function-like macro [ISO/IEC 9899-1999] A #define
preprocessing directive that defines an identifier immediately followed by zero or more parameters, the ellipsis (...
), or a combination of the two, enclosed in parentheses, similar syntactically to a function call. Subsequent instances of the macro name followed by a parenthesized list of arguments in a translation unit are replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive. See also #object-like macro and #unsafe function-like macro. Anchor |
---|
| hosted environment |
---|
| hosted environment |
---|
|
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. Anchor |
---|
| implementation |
---|
| implementation |
---|
|
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. Anchor |
---|
| implementation-defined behavior |
---|
| implementation-defined behavior |
---|
|
implementation-defined behavior [ISO/IEC 9899-1999] Unspecified behavior whereby each implementation documents how the choice is made. Anchor |
---|
| incomplete type |
---|
| incomplete type |
---|
|
incomplete type [ISO/IEC 9899-1999] A type that describes an identifier but lacks information needed to determine the size of the identifier. Anchor |
---|
| indeterminate value |
---|
| indeterminate value |
---|
|
indeterminate value [ISO/IEC 9899-1999] Either an #unspecified value or a #trap representation. Anchor |
---|
| invalid pointer |
---|
| invalid pointer |
---|
|
invalid pointer A pointer that is not a #valid pointer. liveness Every operation or method invocation executes to completion without interruptions, even if it goes against safety. Anchor |
---|
| locale-specific behavior |
---|
| locale-specific behavior |
---|
|
locale-specific behavior [ISO/IEC 9899-1999] Behavior that depends on local conventions of nationality, culture, and language that each implementation documents. lvalue [ISO/IEC 9899-1999] An expression with an object type or an incomplete type other than void
. The name lvalue comes originally from the assignment expression E1 = E2
, in which the left operand E1
is required to be a (modifiable) lvalue. It is perhaps better considered as representing an object "locator value". mitigation [Seacord 2005a] Methods, techniques, processes, tools, or runtime libraries that can prevent or limit exploits against vulnerabilities. Anchor |
---|
| normal termination |
---|
| normal termination |
---|
|
normal termination [Open Group 2008] Normal termination occurs by a return from main()
, when requested with the exit()
, _exit()
, or _Exit()
functions; or when the last thread in the process terminates by returning from its start function, by calling the pthread_exit()
function, or through cancellation. See also #abnormal termination. Anchor |
---|
| object-like macro |
---|
| object-like macro |
---|
|
object-like macro [ISO/IEC 9899-1999] A #define
preprocessing directive that defines an identifier with no parentheses. Subsequent instances of the macro name in a translation unit are replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive. See also #function-like macro. reentrant [Dowd 2006] 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. reliability [IEEE Std 610.12 1990] The ability of a system or component to perform its required functions under stated conditions for a specified period of time. robustness [IEEE Std 610.12 1990] The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions. rvalue [ISO/IEC 9899-1999] Value of an expression. Anchor |
---|
| security flaw |
---|
| security flaw |
---|
|
security flaw [Seacord 2005a] A software defect that poses a potential security risk. Anchor |
---|
| security policy |
---|
| security policy |
---|
|
security policy [Internet Society 2000] A set of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical system resources. Anchor |
---|
| sequence point |
---|
| sequence point |
---|
|
sequence point C99 [ISO/IEC 9899-1999] Evaluation of an expression may produce #side effects. At specific points in the execution sequence called sequence points, all side effects of previous evaluations have completed, and no side effects of subsequent evaluations have yet taken place. Anchor |
---|
| side effects |
---|
| side effects |
---|
|
side effect [ISO/IEC 9899-1999] Changes in the state of the execution environment achieved by accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations. Note: The IEC 60559 standard for binary floating-point arithmetic requires certain user-accessible status flags and control modes. Floating-point operations implicitly set the status flags; modes affect result values of floating-point operations. Implementations that support such floating-point state are required to regard changes to it as side effects. These are detailed in Annex F of the C Standard. Anchor |
---|
| strictly conforming |
---|
| strictly conforming |
---|
|
strictly conforming [ISO/IEC 9899-1999] A strictly conforming program is one that uses only those features of the language and library specified in the international standard. Strictly conforming programs are intended to be maximally portable among conforming implementations and can't, for example, depend on implementation-defined behavior. Anchor |
---|
| trap representation |
---|
| trap representation |
---|
|
trap representation [ISO/IEC 9899-1999] Object representation that does not represent a value of the object type. Attempting to read the value of an object that has a trap representation other than by an expression that has a character type is undefined . Producing such a representation by a #side effect that modifies all or any part of the object other than by an expression that has a character type is undefined. Anchor |
---|
| undefined behavior |
---|
| undefined behavior |
---|
|
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. Anchor |
---|
| unsafe function-like macro |
---|
| unsafe function-like macro |
---|
|
unsafe function-like macro A #function-like macro whose expansion causes one or more of its arguments not to be evaluated exactly once. Anchor |
---|
| unspecified behavior |
---|
| unspecified behavior |
---|
|
unspecified behavior [ISO/IEC 9899-1999] Behavior for which the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance. Anchor |
---|
| unspecified value |
---|
| unspecified value |
---|
|
unspecified value [ISO/IEC 9899-1999] A valid value of the relevant type where the C Standard imposes no requirements on which value is chosen in any instance. An unspecified value cannot be a #trap representation. Anchor |
---|
| valid pointer |
---|
| valid pointer |
---|
|
valid pointer A pointer that refers to an element within an array or one past the last element of an array. For the purposes of this definition, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. (Cf 6.5.8p3) For the purposes of this definition, an object can be considered to be an array of a certain number of bytes; that number is the size of the object, as produced by the sizeof
operator. validation [IEC 61508-4] Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled. Anchor |
---|
| verification |
---|
| verification |
---|
|
verification [IEC 61508-4] Confirmation by examination and provision of objective evidence that the requirements have been fulfilled. Anchor |
---|
| vulnerability |
---|
| vulnerability |
---|
|
vulnerability [Seacord 2005a] A set of conditions that allows an attacker to violate an explicit or implicit security Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e7978e9e-fb33-4124-9f41-424425842b26"><ac:parameter ac:name=""> validation</ac:parameter></ac:structured-macro>
*validation* \[[IEC 61508-4|AA. Bibliography#IEC 61508-4]\]
Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled. |
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="bbe97afc-7eba-42c4-9383-117921615cde"><ac:parameter ac:name=""> verification</ac:parameter></ac:structured-macro>
*verification* \[[IEC 61508-4|AA. Bibliography#IEC 61508-4]\]
Confirmation by examination and provision of objective evidence that the requirements have been fulfilled. |
Wiki Markup |
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="18bf9cdb-00dc-41b7-a321-a1ee9a44d40a"><ac:parameter ac:name=""> vulnerability</ac:parameter></ac:structured-macro>
*vulnerability* \[[Seacord 2005a|AA. Bibliography#Seacord 05]\]
A set of conditions that allows an attacker to violate an explicit or implicit security policy.
...
CERT C Secure Coding Standard CERT C Secure Coding Standard