alt Hacker NewsOne of the tricky things is that undefined behavior is commonly understood as having an unlimited "blast radius" and implementation-defined behavior is commonly understood as not permitting that kind of "blast radius." So any extension point that needed that unlimited "blast radius" had to be undefined behavior. (This has changed somewhat in modern times, but it does hold a little bit today--I'd point you to the discussion of N3863 at the most recent meeting, but I don't have any minutes that I feel really captured that discussion well enough.)
And one of those kinds of "blast radius" is traps, and I suspect the original motivation for making signed integer overflow undefined behavior was precisely to preserve the ability to trap on signed integer overflow, which couldn't be implementation-defined. But the records of the discussions leading up to C89 and C99 are just too fragmentary for me to be certain.
Replies
> And one of those kinds of "blast radius" is traps,
Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
> N3863
Hm?
Because implementation-defined behavior relies on the definition of unspecified behavior, it
means that implementation-defined behavior requires two or more possibilities to be defined in
the standard. However, a brief look at its uses in the standard clearly shows that there isn’t
always a list of potential behaviors to pick from.
N3783 5.2.1.2p1.1: Physical source file multibyte characters are mapped, in an implementation-
defined manner, to the source character set (introducing new-line characters for end-of-line
indicators) if necessary.
N3783 5.2.1.3p1: A conforming implementation shall produce at least one diagnostic message
(identified in an implementation-defined manner)
N3783 5.2.2.2p1-2: In a freestanding environment (in which C program execution can take
place without any benefit of an operating system), the name and type of the function called at
program startup are implementation-defined.
The problem with UB, as evidenced over the years, is that it causes compiler writers to drift much too far from reality, despite the standard itself suggesting "behaving [...] in a documented manner characteristic of the environment" as one of the (better) choices.