3 ms·
The definition of "undefined behavior" did not change in the way you describe between C89/C90 and C99. In both editions, one possible consequence of undefined b
by _kst_ 3y ago
The definition of "undefined behavior" did not change in the way you describe between C89/C90 and C99. In both editions, one possible consequence of undefined behavior is "ignoring the situation completely with unpredictable results" -- i.e., compilers can do whatever they want.
There is no "don't do this" or "please do this" in either edition. Both merely describe the possible consequences if you do.
C90:
undefined behavior: Behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible 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).
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 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."
C99:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data, 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).
EXAMPLE
An example of undefined behavior is the behavior on integer overflow.
(Some of the wording in the C90 definition was moved to the Conformance section in C99.)
- mpweiher 3y ago“Permissible” ≠ “possible”
- _kst_ 3y agoTrue -- but how does that affect the semantics? Both definitions say that undefined behavior can be dealt with by "ignoring the situation completely with unpredictable results". There are no restrictions on what can happen. (The standard joke is that it can make demons fly out of your nose. Of course that's not physically possible, but it would not violate the standard.)
- mpweiher 3y agoIgnoring ≠ taking action based on The standard joke is a joke, because it is wrong.
- nlewycky 3y ago> The standard joke is a joke, because it is wrong. No, it is a joke because it is silly. It is correct and intended for pedagogy.
- muldvarp 3y ago> The standard joke is a joke, because it is wrong. No, it's a joke because it's _physically_ impossible but allowed. That said, clang and gcc are of course not antagonistic and don't make use of UB to anger their users. Instead, they make use of UB to aggressively optimize (valid) programs, which is important because C is used for a lot of high-performance code where every bit of optimization can save a lot of time and money. The fact that this sometimes leads to invald programs (i.e. programs with no defined behavior according to the standard) being optimized to correct but "absurd" results is just a trade-off compiler writers like to take. Mostly because such programs are erroneous anyway, even under a strict "portable assembler" view, which again the standard does not enforce (or even encourage).
- deleted 3y ago[deleted]