5 ms·
My thought process, note that I am not a compiler writer, runs along these lines. undefined behavior is valid code(it is not a syntax error), it has to do some
by somat 4y ago
My thought process, note that I am not a compiler writer, runs along these lines.
undefined behavior is valid code(it is not a syntax error), it has to do some thing, that thing should be documented, if the spec does not want to document it, then the implementation should. don't make the assumption that because it is undefined it will never happen.
- jcranmer 4y agoIt is not practical to constrain what happens in the case of undefined behavior, even if you discard the potential of the compiler to optimize assuming undefined behavior can't happen. For example, what memory has and hasn't been written when a trap occurs isn't. Hell, on some architectures (hi Alpha!), an unknown amount of code will continue executing after the trapping instruction before the trap handler gets around to being invoked. Similar insanity is also in play when data races are involved (if data races are undefined, you can pretend that all code is sequentially consistent and there is a nice, simple, global total order of memory accesses. Data races cause memory accesses to not even be a consistent partial order.) Or take pointer provenance. Writing to an unknown memory location may cause printf in another thread to instead call system("rm -rf /"). How the hell is one supposed to document the potential behavior of undefined behavior when undefined behavior is so inherently unconstrainable, and "undefined behavior can do anything" is considered unacceptable documentation?
- pklausler 4y agoWhat you're talking about is "implementation defined" behavior, which is a distinct concept from "undefined behavior".