alt Hacker NewsN3863 is one of those papers where what the paper proposed and what was actually discussed in the meeting ended up being rather different things, and it's the meeting discussion that I'm pointing to, not the paper itself.
> 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.
Unspecified behavior also isn't allowed to be a trap. The difference between unspecified and implementation-defined is whether or not the compiler has to document its choice; the difference between unspecified and undefined is whether or not the choice is limited.
There is already a precedent for a signed integer operation to produce an implementation-defined value or to trap. It's for integer conversion:
https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subsu...
> Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.
There is no reason that this wording strategy could not be reused for bit shifts.
In general there is no constraint that unspecified or implementation-defined behavior can't be a trap. Without further qualification "unspecified behavior" or "implementation-defined behavior" is still open-ended, and it's up to the surrounding standard text to restrict the behavior further.
https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subse...
> 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
"Possibilities" include trap