Undefined behaviour (UB) is defined by the ISO/ANSI C Standard as:
behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements
NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
The C99 version of the Standard removed "indeterminately valued objects" from this definition - in C99 the use of indeterminately valued objects is unspecified behaviour.
Explicit and implicit UB
Section 4, paragraph 2 of the Standard explains undefined behaviour further:
If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’.
So aside from the Standard explicitly pointing out areas of undefined behaviour, anything that it (deliberately or carelessly) does not specify is implicitly undefined behaviour - no less significant than the other forms.
Quick examples
Explicit UB
This code snippet produces undefined behaviour:
i = i++;
because section 6.5, paragraph 2 of the Standard requires that [b]etween the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression.
Here the entire snippet is an expression, which attempts to modify i by using both the post-increment operator and the assignment operator without an intervening sequence point. Sequence points are described in Annex C of the Standard and can be summarised as special places in the code where effects are guaranteed to have taken place - the assignment operator is not one of those places. So the "shall" condition of 6.5#2 - not part of a constraint - is violated, and therefore by 4#2, the behaviour is undefined.
See also
References
- ISO C Standard, 3.4.3
- ISO C Standard, 4 paragraph 2
