2 ms·
Undefined behavior was, in most cases, intended to encompass a point where different implementations behaved in reasonable ways. In case of overflow, some imple
by inigyou 4mo ago
Undefined behavior was, in most cases, intended to encompass a point where different implementations behaved in reasonable ways. In case of overflow, some implementations wrapped, some saturated, some threw an exception, some jumped to an interrupt handler, and some returned 0. They made it undefined intending to encompass all of these. Notice they are all fairly reasonable (except for returning 0).
Later, stupid compiler writers decided that since the wording allows anything to happen, it also allows time travel or memory corruption. These are not reasonable, but they are allowed by the wording of the standard.
The standard should be fixed to say it returns an undefined value or activates an error handling mechanism. Nobody could argue that time travel is an error handling mechanism.
- aw1621107 4mo ago> They made it undefined intending to encompass all of these. Why wouldn't implementation-defined behavior suffice in this case?
- inigyou 4mo agoIB means the implementation has to fully document what it does. Evidently they didn't want to impose that requirement.
- aw1621107 4mo agoThere's always unspecified behavior if documentation is considered to be too onerous.
- UncleMeat 4mo agoIt also means that the behavior needs to be stable across time and that tools cannot report this behavior as a bug.
- aw1621107 4mo ago> It also means that the behavior needs to be stable across time I don't think IB has to be stable over time? For instance, whether and which extended integer types exist is IB and that has definitely changed over time. > and that tools cannot report this behavior as a bug. It's absolutely possible to report IB as a bug (or even fully-specified behavior, as demonstrated by -fsanitize=unsigned-integer-overflow or -fsanitize=implicit-integer-conversion).