| Anchor |
|---|
| abnormal termination |
|---|
| abnormal termination |
|---|
|
abnormal termination [Open Group 08] Abnormal termination occurs when requested by the abort() function or when some signals are received.| Anchor |
|---|
| application binary interface |
|---|
| application binary interface |
|---|
|
application binary interfaceAn application binary interface is an interface between two independently compiled modules of a program. An Application Binary Interface document specifies a set of conventions such as the order and location of function arguments that compilers must adhere to in order to achieve interoperability between such modules.| Anchor |
|---|
| basic exception safety |
|---|
| basic exception safety |
|---|
|
basic exception safety [Stroustrup 01, Sutter 00] The basic exception safety guarantee is a property of an operation such that, if the operation terminates by raising an exception, it preserves program state invariants and prevents resource leaks. (See also exception safety and strong exception safety.)Clang
Clang is an open source C and C++ compiler. More information can be found at http://clang.llvm.org/.| Anchor |
|---|
| condition predicate |
|---|
| condition predicate |
|---|
|
condition predicateA condition predicate is an expression constructed from the variables of a function that must be true for a thread to be allowed to continue execution.| Anchor |
|---|
| conforming program |
|---|
| conforming program |
|---|
|
conforming [ISO/IEC 14882-2014]Conforming programs may depend on nonportable features of a conforming implementation.| Anchor |
|---|
| criticalsections |
|---|
| criticalsections |
|---|
|
critical sections
Critical sections are code that accesses shared data and that would otherwise be protected from data races.cv-qualify
To cv-qualify a type is to add const or volatile (or both) to the type. data race [ISO/IEC 14882-2014]The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other. [An exception is]that two accesses to the same object of type volatile sig_atomic_t do not result in a data race if both occur in the same thread, even if one or more occurs in a signal handler. deadlock [ISO/IEC 14882-2014]
A deadlock is when one or more threads are unable to continue execution because each is blocked waiting for one or more of the others to satisfy some condition| Anchor |
|---|
| denial-of-service |
|---|
| denial-of-service |
|---|
|
denial-of-service attack A denial-of-service attack is an attempt to make a computer resource unavailable to its intended users.| Anchor |
|---|
| diagnostic message |
|---|
| diagnostic message |
|---|
|
diagnostic message [ISO/IEC 14882-2014]
A diagnostic message is a message belonging to an implementation-defined subset of the implementation’s message output. A diagnostic message may indicate a constraint violation or a valid, but questionable, language construct. Messages typically include the file name and line number pointing to the offending code construct. In addition, implementations also often indicate the severity of the problem. Although the C++ Standard does not specify any such requirement, the most severe problems often cause implementations to fail to fully translate a translation unit. Diagnostics output in such cases are termed errors. Other problems may cause implementations simply to issue a warning message and continue translating the rest of the program. (See error message and warning message.)
| Anchor |
|---|
| error message |
|---|
| error message |
|---|
|
error messageAn error message is a diagnostic message generated when source code is encountered that prevents an implementation from translating a translation unit. (See diagnostic message and warning message.)| Anchor |
|---|
| exception safety |
|---|
| exception safety |
|---|
|
exception safety [Stroustrup 01] An operation on an object is said to be exception safe if that operation leaves the object in a valid state when the operation is terminated by throwing an exception. (See also basic exception safety and strong exception safety.) exploit [Seacord 2005] An exploit is a piece of software or technique that takes advantage of a security vulnerability to violate an explicit or implicit security policy.| Anchor |
|---|
| fatal diagnostic |
|---|
| fatal diagnostic |
|---|
|
fatal diagnosticA fatal diagnostic is a message that causes an implementation not to perform the translation. free store [ISO/IEC 14882-2014]The free store is storage managed by the C++ allocation and deallocation functions ::operator new(std::size_t), ::operator delete(void*), their array forms ::operator new[](std::size_t), ::operator delete[](void*), overloads of said functions on std::nothrow_t, any user-defined replacements for said functions, as well as any such functions defined as a member of a class. Storage in the free store is distinct from storage managed by the C functions calloc(), free(), malloc(), and realloc().GCCGCC is an open source C and C++ compiler. More information can be found at https://gcc.gnu.org/.| Anchor |
|---|
| ill-formed program |
|---|
| ill-formed program |
|---|
|
ill-formed program [ISO/IEC 14882-2014] An ill-formed program is a C++ program that is not well-formed; that is, a program not constructed according to the syntax rules, diagnosable semantic rules, and the one-definition rule.| Anchor |
|---|
| implementation |
|---|
| implementation |
|---|
|
implementation [ISO/IEC 9899:2011] An implementation is a 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 14882-2014]Implementation-defined behavior is behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents.| Anchor |
|---|
| incomplete type |
|---|
| incomplete type |
|---|
|
incomplete type [ISO/IEC 14882-2014]A class that has been declared but not defined, an enumeration type in certain contexts, an array of unknown size or of incomplete element type, and the void type are incomplete types. These types lack the information required to determine the size of the type.| Anchor |
|---|
| indeterminate value |
|---|
| indeterminate value |
|---|
|
indeterminate value [ISO/IEC 14882-2014]When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced.| Anchor |
|---|
| invalid pointer |
|---|
| invalid pointer |
|---|
|
invalid pointer An invalid pointer is a pointer that is not a valid pointer.libc++libc++ is an open source Standard Template Library (STL) implementation. More information can be found at http://libcxx.llvm.org/.libstdc++libstdc++ is an open source Standard Template Library (STL) implementation. More information can be found at https://gcc.gnu.org/onlinedocs/libstdc++/.livenessLiveness is when every operation or method invocation executes to completion without interruptions, even if it goes against safety. lvalue [ISO/IEC 14882-2014]An lvalue (so called, historically, because lvalues could appear on the left-hand side of an assignment expression) designates a function or an object.Microsoft Visual StudioMicrosoft Visual Studio is a commercial C and C++ compiler. More information can be found at https://www.visualstudio.com/.Microsoft Visual Studio STLThe Microsoft Visual Studio STL is a commercial Standard Template Library (STL) implementation. More information can be found at https://msdn.microsoft.com/en-us/library/cscc687y.aspx mitigation [Seacord 2005] A mitigation is a method, technique, process, tool, or runtime library that can prevent or limit exploits against vulnerabilities.| Anchor |
|---|
| one definition rule |
|---|
| one definition rule |
|---|
|
one-definition rule (ODR) [ISO/IEC 14882-2014] A fundamental C++ rule that states that no translation unit shall contain more than one definition of any variable, function, class type, enumeration type or template, and that every program shall contain exactly one definition of every non-inline function or variable. Some definitions may be duplicated in multiple translation units, subject to strict rules.
ODR-use [ISO/IEC 14882-2014]
A function or object is ODR-used if the address of the entity is taken, the function is called, or a reference is bound to the object. When a function or object is ODR-used, its definition must exist within the program or else the program is ill-formed.
RAII (Resource Acquisition Is Initialization)
RAII is a design principle supported by C++. Holding a resource is a class invariant where the allocation of the resource (acquisition) is inseparable from the initialization of the object during its construction. Further, deallocation of the resource is performed during the destruction of the object. Thus, the resource is held when initialization completes and remains held until finalization begins, ensuring there are no resource leaks unless the object owning the resource is also leaked.
reliability [IEEE Std 610.12 1990] Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time.| Anchor |
|---|
| restricted sink |
|---|
| restricted sink |
|---|
|
restricted sink [ISO/IEC 9899:2011]A restricted sink is an operand or argument whose domain is a subset of the domain described by its type. rvalue [ISO/IEC 14882-2014]An rvalue (so called, historically, because rvalues could appear on the right-hand side of an assignment expression), is an xvalue, a temporary object or subobject thereof, or a value that is not associated with an object.| Anchor |
|---|
| security flaw |
|---|
| security flaw |
|---|
|
security flaw [Seacord 2005] A security flaw is a software defect that poses a potential security risk.| Anchor |
|---|
| security policy |
|---|
| security policy |
|---|
|
security policy [Internet Society 2000]A security policy is 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 |
|---|
| strong exception safety |
|---|
| strong exception safety |
|---|
|
strong exception safety [Stroustrup 2001, Sutter 2000] The strong exception safety guarantee is a property of an operation such that, in addition to satisfying the basic exception safety guarantee, if the operation terminates by raising an exception, it has no observable effects on program state. (See also exception safety and basic exception safety.)SFINAESFINAE (Substitution Failure Is Not An Error) is a language rule applied by the compiler during overload resolution involving templates. In some contexts, when substituting a template type parameter fails, the specialization is discarded from the overload set instead of causing a compile error. This feature is used in template metaprogramming.| Anchor |
|---|
| tainted source |
|---|
| tainted source |
|---|
|
tainted source [ISO/IEC TS 17961:2012]A tainted source is an external source of untrusted data.| Anchor |
|---|
| tainted value |
|---|
| tainted value |
|---|
|
tainted value [ISO/IEC TS 17961:2012]A tainted value is a value derived from a tainted source that has not been sanitized.| Anchor |
|---|
| trust boundary |
|---|
| trust boundary |
|---|
|
trust boundary
A trust boundary is a boundary between a trusted execution context (or trusted data source) in which all sub-execution contexts (or data sources) are trusted by the system and a nontrusted execution context (or nontrusted data sink).| Anchor |
|---|
| undefined behavior |
|---|
| undefined behavior |
|---|
|
undefined behavior [ISO/IEC 14882-2014] Undefined behavior is behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which the C++ Standard imposes no requirements. Undefined behavior may also be expected when the C++ Standard omits the description of any explicit definition of behavior or defines the behavior to be ill-formed, with no diagnostic required.| Anchor |
|---|
| unspecified behavior |
|---|
| unspecified behavior |
|---|
|
unspecified behavior [ISO/IEC 14882-2014] Unspecified behavior is behavior, for a well-formed program construct and correct data, that depends on the implementation. The implementation is not required to document which behavior occurs.| Anchor |
|---|
| unspecified value |
|---|
| unspecified value |
|---|
|
unspecified value [ISO/IEC 9899:2011] An unspecified value is a valid value of the relevant type where the C++ Standard imposes no requirements on which value is chosen in any instance.| Anchor |
|---|
| valid pointer |
|---|
| valid pointer |
|---|
|
valid pointer A valid pointer is 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. 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.vtable
A vtable is a common implementation technique to support dynamic method dispatch, where a class object instance includes a hidden data member that is a pointer to an array of function pointers used to resolve virtual function calls at runtime.| Anchor |
|---|
| vulnerability |
|---|
| vulnerability |
|---|
|
vulnerability [Seacord 2005] A vulnerability is a set of conditions that allows an attacker to violate an explicit or implicit security policy.| Anchor |
|---|
| warning message |
|---|
| warning message |
|---|
|
warning messageA warning message is a diagnostic message generated when source code is encountered that does not prevent an implementation from translating a translation unit. (See diagnostic message and error message.)| Anchor |
|---|
| well-formed program |
|---|
| well-formed program |
|---|
|
well-formed program [ISO/IEC 14882-2014]A well-formed program is a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the one-definition rule. (See also ill-formed program.)xvalue [ISO/IEC 14882-2014]An xvalue (an "eXpiring" value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example). An xvalue is the result of certain kinds of expressions involving rvalue references.
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="ead37366-113a-4403-b6be-bf4adea6bcfa"><ac:parameter ac:name=""> asynchronous-safe</ac:parameter></ac:structured-macro>
*asynchronous-safe* \[[GNU Pth|AA. C References#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. 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 asynchronous-safe. If a function performs any other operations, it is probably not asynchronous-safe.
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="cb4e50fa-0bed-435c-a2ff-f2ef3c8dd49d"><ac:parameter ac:name=""> availability</ac:parameter></ac:structured-macro>
*availability* \[[IEEE Std 610.12 1990|AA. C References#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="920ff974-77bb-4864-a242-e04cb3475a5f"><ac:parameter ac:name=""> basic exception safety</ac:parameter></ac:structured-macro>
*basic exception safety* \[[Stroustrup 01|AA. C++ References#Stroustrup 01]\], \[[Sutter 00|AA. C++ References#Sutter 00]\]
The basic exception safety guarantee is a property of an operation such that, if the operation terminates by raising an exception, it preserves program state invariants and prevents resource leaks. See also: [exception safety|BB. Definitions#exception safety], [strong exception safety|BB. Definitions#strong exception safety], [no-throw guarantee|BB. Definitions#no-throw guarantee]. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b0d11c21-22e0-4d0d-b2ff-99903622f9a1"><ac:parameter ac:name=""> conforming program</ac:parameter></ac:structured-macro>
*conforming* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Conforming programs may depend upon nonportable features of a conforming implementation. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="d3ebef06-47d5-4e94-a935-ec6e099c180a"><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="eae7bf92-d9cc-465a-a7f5-39e3dc29a09c"><ac:parameter ac:name=""> error tolerance</ac:parameter></ac:structured-macro>
*error tolerance* \[[IEEE Std 610.12 1990|AA. C References#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="29432e11-f40c-4f63-890d-186a68c51d3f"><ac:parameter ac:name=""> exception safety</ac:parameter></ac:structured-macro>
*exception safety* \[[Stroustrup 01|AA. C++ References#Stroustrup 01]\]
An operation on an object is said to be exception safe if that operation leaves the object in a valid state when the operation is terminated by throwing an exception. See also: [basic exception safety|BB. Definitions#basic exception safety], [strong exception safety|BB. Definitions#strong exception safety], [no-throw guarantee|BB. Definitions#no-throw guarantee]. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="cfa7f6f2-ccc3-4c4a-906e-3c24014f36e5"><ac:parameter ac:name=""> exploit</ac:parameter></ac:structured-macro>
*exploit* \[[Seacord 05a|AA. C References#Seacord 05]\]
An exploit is a piece of software or 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="0981f9f7-beb8-4c13-8275-7838f5c9ef85"><ac:parameter ac:name=""> fail safe</ac:parameter></ac:structured-macro>
*fail safe* \[[IEEE Std 610.12 1990|AA. C References#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="0e729570-7a5a-4edc-9379-43c9ed9d1dc4"><ac:parameter ac:name=""> fail soft</ac:parameter></ac:structured-macro>
*fail soft* \[[IEEE Std 610.12 1990|AA. C References#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="2b110f26-fbc2-42aa-9cd3-51d6f5810224"><ac:parameter ac:name=""> fault tolerance</ac:parameter></ac:structured-macro>
*fault tolerance* \[[IEEE Std 610.12 1990|AA. C References#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="da2593d5-a287-43e8-b27e-25fbcfe37710"><ac:parameter ac:name=""> freestanding environment</ac:parameter></ac:structured-macro>
*freestanding environment* \[[ISO/IEC 9899-1999|AA. C References#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="2eb334d2-b42b-49ad-b323-fe17bf9c2b2a"><ac:parameter ac:name=""> hosted environment</ac:parameter></ac:structured-macro>
*hosted environment* \[[ISO/IEC 9899-1999|AA. C References#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="68564a37-953d-4095-a7a9-1c1b8ad9cb6e"><ac:parameter ac:name=""> implementation</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="d0b5d1ed-15a4-43c7-93d9-8bf476ff83a9"><ac:parameter ac:name=""> implementation-defined behavior</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="fe51861a-3fe7-4be0-a415-2158c010ab47"><ac:parameter ac:name=""> incomplete type</ac:parameter></ac:structured-macro>
*incomplete type* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
An incomplete type is 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="472db4b0-5a33-44a6-8ed9-3ebe154e7fb9"><ac:parameter ac:name=""> locale-specific behavior</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="77fae060-fb03-4855-9ca1-450ae818b53e"><ac:parameter ac:name=""> lvalue</ac:parameter></ac:structured-macro>
*lvalue* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
An lvalue is 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="9b049658-8903-42bd-8ec9-6b7e13dc305a"><ac:parameter ac:name=""> mitigation</ac:parameter></ac:structured-macro>
*mitigation* \[[Seacord 05a|AA. C References#Seacord 05]\]
Mitigations are 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="0628c0af-52f4-4bde-b570-7aa7d73a00a5"><ac:parameter ac:name=""> no-throw guarantee</ac:parameter></ac:structured-macro>
*no-throw guarantee* \[[Sutter 00|AA. C++ References#Sutter 00]\]
The no-throw guarantee is a property of an operation such that it is guaranteed to complete successfully without raising or propagating an exception. See also: [exception safety|BB. Definitions#exception safety], [basic exception safety|BB. Definitions#basic exception safety], [strong exception safety|BB. Definitions#strong exception safety]. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="9cded480-a8b2-42d2-a496-fe63cd865ced"><ac:parameter ac:name=""> reentrant</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b164ba7d-6079-4991-a06f-b50bcad3d856"><ac:parameter ac:name=""> reliability</ac:parameter></ac:structured-macro>
*reliability* \[[IEEE Std 610.12 1990|AA. C References#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="8584ade0-b9b4-44a4-aa9c-9db854135784"><ac:parameter ac:name=""> robustness</ac:parameter></ac:structured-macro>
*robustness* \[[IEEE Std 610.12 1990|AA. C References#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="67a07e00-e7eb-41f5-8fda-d1e7dbbbfe93"><ac:parameter ac:name=""> rvalue</ac:parameter></ac:structured-macro>
*rvalue* \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]
Value of an expression. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="f9ea6e63-c907-4e60-a58d-d552095fd573"><ac:parameter ac:name=""> security flaw</ac:parameter></ac:structured-macro>
*security flaw* \[[Seacord 05a|AA. C References#Seacord 05]\]
A security flaw is a software defect that poses a potential security risk. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="ed1d126e-42b6-40bb-952c-b438dc04c8ab"><ac:parameter ac:name=""> security policy</ac:parameter></ac:structured-macro>
*security policy* \[[Internet Society 00|AA. C References#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="e18dd6ba-d3ca-4e94-b777-9df4c4693205"><ac:parameter ac:name=""> sequence point</ac:parameter></ac:structured-macro>
*sequence point* C99 \[[ISO/IEC 9899-1999|AA. C References#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 |
|---|
The following sequence points are defined by C99 \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]: |
- the call to a function, after the arguments have been evaluated
- the end of the first operand of the following operators: && (logical AND); || (logical OR); ? (conditional); , (comma operator)
- the end of a full declarator
- the end of a full expression: an initializer; the expression in an expression statement (that is, at the semicolon); the controlling expression of a selection statement (if or switch); the controlling expression of a while or do statement; each of the expressions of a for statement; the expression in a return statement
- immediately before a function returns
- after the actions associated with each formatted input/output function conversion specifier
- immediately before and immediately after each call to a comparison function, by a standard searching or sorting function, and between any call to a comparison function and any movement of the objects passed as arguments to that call
Note that not all instances of a comma in C code denote a usage of the comma operator. For example, the comma between arguments in a function call is not a sequence point.
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="f84d1191-bdc3-4752-8f0c-e2ccf8ca654a"><ac:parameter ac:name=""> strictly conforming</ac:parameter></ac:structured-macro>
*strictly conforming* \[[ISO/IEC 9899-1999|AA. C References#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 upon implementation-defined behavior. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="51b41485-214e-4191-bcde-189d5ee7a536"><ac:parameter ac:name=""> strong exception safety</ac:parameter></ac:structured-macro>
*strong exception safety* \[[Stroustrup 01|AA. C++ References#Stroustrup 01]\], \[[Sutter 00|AA. C++ References#Sutter 00]\]
The strong exception safety guarantee is a property of an operation such that, in addition to satisfying the [basic exception safety|BB. Definitions#basic exception safety] guarantee, if the operation terminates by raising an exception it has no observable effects on program state. See also: [exception safety|BB. Definitions#exception safety], [basic exception safety|BB. Definitions#basic exception safety], [no-throw guarantee|BB. Definitions#no-throw guarantee]. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="f34a0897-cd8a-4ca0-bd52-d5a55555e603"><ac:parameter ac:name=""> undefined behavior</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="744b92c8-b637-4f57-a150-4d8ed02cd6ca"><ac:parameter ac:name=""> unspecified behavior</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b713ca10-182f-47e1-8903-95f047ae2aa6"><ac:parameter ac:name=""> validation</ac:parameter></ac:structured-macro>
*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. |
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b9209b6e-f900-4b29-8ce5-3b84ec9773e5"><ac:parameter ac:name=""> verification</ac:parameter></ac:structured-macro>
*verification* \[[IEC 61508-4|AA. C References#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="5206efb8-72b9-4c71-9459-7879c2bf5be3"><ac:parameter ac:name=""> vulnerability</ac:parameter></ac:structured-macro>
*vulnerability* \[[Seacord 05a|AA. C References#Seacord 05]\]
A vulnerability is a set of conditions that allows an attacker to violate an explicit or implicit security policy.
