Does this answer your question? Why would a language have a concept of undefined behavior instead of raising an error?

‘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%.

I don't know the answer to your question, but it reminds me of this 2014 blog post from Raymond Chen that you might find interesting. devblogs.microsoft.com/oldnewthing/20140627-00/?p=633

@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.

Does your function expose UB at all? It will not terminate with the majority of arguments for test1, but is that UB? Seems very well DB for me.

@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 How does one conclude that from the wording?

@Peter-ReinstateMonica: Are you looking at the same wording I am or some inexact paraphrase?

@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: "empty loops" doesn't appear in the rule. The rationale is non-binding and has no effect whatsoever.

@BenVoigt: The Standard specifies the kinds of language that invite "undefined behavior". Is the phrase "may assume" among them?

@supercat THat is about my question. I thought not. Because then one should have written it that way.

@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?

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?

@Peter-ReinstateMonica Let’s just say I have functionally been “on strike” on Stack Overflow for the past several years ;)

But programming languages are my dayjob, and this site is very young. So it is a little more near and dear to my heart.

(Context, for clarity:

So I will delete your comments. But no hard feelings. :)

:-)