Some language specifications invite compilers to make certain assumptions, and behave in completely arbitrary fashion if such functions are violated, even if the code in question would have unambiguously defined behavior in the absence of such invitation and assumption. This is done to uphold th...
‘If a program has received input which--for some combination of unspecified behaviors--could result in a function being invoked with certain argument values without any additional input being received’ – what does this condition even mean? Can’t you just skip it?
@user3840170: Suppose code contains a function int foo{int x) { return 10000/x;}. If a program doesn't receive any inputs that would result in a call foo(0); a compiler would not be allowed to generate one, but if e.g. code were to perform do { ...some code that will not block... ; z = foo(y); } while(whatever);` a compiler would be allowed to replace the call to foo(y) inside the loop with one before the loop, without regard for whether y might be zero.
You are ignoring the fact that the set of optimizations evolves over time. If your language specification whitelists a certain set of optimizations, you forbid other optimizations. I consider it very salient that you are making an infinite number bleeding-edge compiler changes, which might lead to updates to the language specification, formally nonconforming. We learned the hard way how advantageous it is to prototype potential new requirements before putting them in the spec.
@BenVoigt: It's possible to add directives to invite additional kinds of behavioral deviations, though in many cases the performance benefits would be slight (if existing rules would allow a compiler to generate code whose performance is within 10% of the optimal code that would meet requirements, but compilers miss low hanging fruit which costs them 20%, allowing new deviations to let compilers go after that 10% would be less useful than having compiler writers direct their efforts toward the easy 20%.
@EricLippert: "Time travel" requires nothing more than performing unrelated operations out of sequence. What's weirder is the way that laws of causality get thrown out the window, and a statement like uint1 = ushort1*ushort2; can change the value of expressions involving ushort1 if it exceeds INT_MAX/ushort2.
@Peter-ReinstateMonica: In C++, failure of an otherwise-side-effect-free loop to terminate invokes UB, and may thus trigger side effect including arbitrary memory corruption. Both clang and gcc will sometimes process calls to that function which ignore the return value in ways that will unconditionally store 1 to arr[x] without regard for whether x is less than 65536.
@Bbrk24: The linked suggested duplicate does not answer the question, since it addresses the question of why some actions must be UB, rather than the question of whether adding language rules which would classify as UB *actions which would be defined in those rules' absence" is as useful for optimization as much as other safer ways of facilitating optimization.
I stumbled across Hans-J. Boehm's N1528 defending the decision to allow compilers to consider loops as terminating, as opposed to N1509 which suggested to take things literally.
By the way, I still don't see the UB in the general case. Is the UB not restricted to cases where eliminating the "empty" loop introduces a data race which would not be there if the loop were present? An example for hat is the somewhat contrived merge-loop example discussed e.g. here. Everything else (e.g. programs terminating regularly, but unexpected because control flow passes an "infinite" loop) is unexpected but not undefined.
@Peter-ReinstateMonica: No, the UB applies to any condition which causes a loop to never have a visible side effect (read or write volatile, do I/O, synchronize, exit).
@BenVoigt: A problem with the wording is that it doesn't clarify what "empty loops" means. If code as written does not rely for correctness upon a loop's exit condition having been established before the execution of following code, but a compiler transforms a program in a manner that does rely upon that, is the loop "empty"?
@supercat: No, the Standard does not so specify. "The Standard specifies the kinds of language that invite undefined behavior." is simply incorrect. What made you think that?
@BenVoigt: In general English usage, an invitation to "assume" something implies permission to perform certain actions as though the assumption was true, without regard for whether it actually is. The "rationale" offers a purpose for which the assumption might be exploited.
For some reason, people seem to think the Standdard was written to precisely and unambiguously partition programs into those that have defined behavior and those that are erroneous, without recognizing that the authors of the Standard sometimes don't bother to specify all of the corner cases that should be defined.
@BenVoigt: I'm not as familiar with the C++ Standard as the C Standard, but N1570 4p2 says 'If a ''shall'' or ''shall not'' requirement that appears outside of a constraint or runtime- constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ''undefined behavior'' or by the omission of any explicit definition of behavior.'
@BenVoigt: Does the C++ Standard not say something similar?
Discussion on question by supercat: P…
Discussion on question by supercat: P…