The C standard defines the terms “undefined behavior”, “unspecified behavior” and “implementation-defined behavior” for certain kinds of behavior that are not fully specified by the standard. (For the purposes of this paper, locale-specific behavior is treated as a variant of implementation-defined behavior.) These may be classified on two axes: whether there are bounds on the behavior in question (permitting formal or informal reasoning about a program that encounters the situation with such behavior, without reference to implementation documentation), and whether the implementation is required to document the behavior. A third axis is often also relevant, though not considered explicitly in the standard: whether the behavior is a property of a program or of a particular execution of a program. (Undefined behavior as a property of a program may result in failed translation; undefined behavior as a property of a particular execution cannot result in failed execution unless it is a property of all possible executions; see the response to C90 issue 0109.)
| Documented | Undocumented | |
|---|---|---|
| Bounded | implementation-defined | unspecified |
| Unbounded | no name, the subject of this paper | undefined |
Unspecified behavior is defined as “behavior, that results
from the use of an unspecified value, or other behavior upon which
this document provides two or more possibilities and imposes no
further requirements on which is chosen in any instance”, and
implementation-defined behavior as “unspecified behavior where
each implementation documents how the choice is made”. It has
been noted that many places described as implementation-defined do not
in fact meet the requirement that the standard provides a defined
enumeration of possibilities (although in many other places, such an
enumeration is implicit in the bounds on the semantics given by the
normative text; for example, while the result of sizeof
is implementation-defined, it must be a value of
type size_t which agrees with the representation of the
type in question). This applies particularly to cases of
implementation-defined behavior as an extension point, where it may
not be possible to enumerate all the ways such an extension can
behave, and where an implementation may wish to leave some cases
undefined while defining others.
Previous proposals in this area include N3863, discussed at the August 2026 meeting, which would have reallocated the term “implementation-defined” from the (bounded, documented) combination to the (unbounded, documented) combination, and N3710, discussed at the March 2026 meeting, which would have introduced a term “extensible behavior”.
This paper proposes introducing a term “implementation-documented” for the currently unnamed (unbounded, documented) combination, without introducing other new concepts, and without redefining any existing term. (But it is possible that the “provides two or more possibilities” in the definition of “unspecified behavior” should also be rephrased to clarify that it refers to the standard bounding the possible choices, explicitly or implicitly, rather than necessarily providing a fully explicit list.)
No change is needed regarding “implementation-defined value” because the type of a value already implicitly determines what the possible choices are.
Note that if behavior in a particular case is changed from undefined to implementation-documented, it is only possible to reason about that behavior for a particular program using information from the implementation documentation. Since an implementation could choose to document such behavior as undefined, the difference between undefined and implementation-documented behavior is largely a matter of emphasis: undefined behavior is typically associated with erroneous cases that programs should avoid, while implementation-documented behavior is typically associated with nonportable cases that programs might choose to rely upon when requiring an implementation that has made certain choices or implements certain extensions.
The subclause references here are relative to the N3886 working draft. These changes are intended for discussion and an along-the-lines vote, on the basis that if the direction is supported (possibly with a different name), a full proposal would then identify exactly which instances of implementation-defined behavior are intended to use the new term.
After “implementation-defined behavior” (3.5.1) insert a new definition.
3.5.1' implementation-documented behavior
implementation-documented behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data, that each implementation documents; an implementation can document that the behavior in a particular case is undefined or unspecified
In the definition of “strictly conforming program” (clause 4), insert:
A strictly conforming program shall use only those features of the language and library specified in this document. It shall not produce output dependent on any unspecified, undefined, implementation-documented, or implementation-defined behavior, and shall not exceed any minimum implementation limit.
In clause 4 paragraph 10, insert:
An implementation shall be accompanied by a document that defines all implementation-defined, implementation-documented, and locale-specific characteristics and all extensions.
In 5.2.1.3 Diagnostics, insert:
A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined, implementation-documented, or implementation-defined. Diagnostic messages are not required to be produced in other circumstances.
One of the most unambiguous examples of what should be “implementation-documented” because there cannot be any reasonable bounds expressed on what the behavior might be is in 6.7.12 Attributes; a representative change in this regard (the full proposal would have many more such changes) is in 6.7.12.1 paragraph 2:
Support for any of the standard attributes specified in this document is implementation-defined and optional. For an attribute token (including an attribute prefixed token) not specified in this document, the behavior is
implementation-definedimplementation-documented. Any attribute token that is not supported by the implementation is ignored.
In Annex J, insert a new subclause after J.3 Implementation-defined behavior. The detailed contents (to be moved from J.3) would appear in the full proposal. Where, in the course of writing the full proposal, cases of implementation-defined behavior are discovered to be missing from J.3, or to have entries in J.3 that are out of sync with the normative text, those cases would be fixed editorially in J.3 rather than through a paper.
J.3' Implementation-documented behavior
J.3'.1 General
A conforming implementation is required to document its choice of behavior in each of the areas listed in this subclause. The following are implementation-documented: