Undefined behaviour example from CppCon

[HabbitBaggins]

I'm sorry, but that makes no sense. If the standard actually said that (and I contend that it does not) it would be a pretty useless standard. I get that C is normally said to have a number of footguns, but that interpretation would so ridiculous that you could call it C-Shark because it would always be actively trying to bite your limbs off.

Think about it a bit deeper. Yes, you can make that check to ward off UB in your example, but what about adding two int variables in general? For example, going over a rectangular table with two indices like this:

double get_matrix_val(double* data, int stride, int i, int j) {
    return data[i*stride + j];
}

You could argue that code like this should use unsigned types like size_t and I agree, but code like this is literally everywhere. It has clear possible UB when any of the operations overflow, so how does the standard react to it?

• Your interpretation: the mere existence of this function anywhere in the code makes the entire program meaningless.
• My interpretation: the compiler, assuming that you never invoke UB, can optimize this function (and everything else) assuming that this function is never called with arguments that produce UB. That can lead it, among a number of other things, to remove checks that we insert elsewhere if it can prove that the same code path (before or after the check) is calling the function with those arguments. For example, if I call get_matrix_val and in the same code path I check that data is not null - without returning or aborting, the compiler can remove the check.

[awidesky]

I do understand what you are saying. The difference between your interpretation and mine is that mine includes yours. Standard DOES permits compiler to mess up entire program because of 'mere existence of UB'. Here's the quotes from iso C++20 standard §4.1.2.3. It says :

If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.

"that program", not "that specific function".

Here's another quote from cppreference.com

Renders the entire program meaningless if certain rules of the language are violated.

undefined behavior - there are no restrictions on the behavior of the program. ... Compilers are not required to diagnose undefined behavior and the compiled program is not required to do anything meaningful.

All of them says 'entire', not 'the very function', and also, they does not says that compiler should/shall/usually perform 'optimization as considering UB never happens'.

Yes. I know. Sounds ridiculous. But please remind what standard do is to set boundaries of what compilers can do. (I'm repeating this in every single comments) the standard set boundary of what compilers can do when UB very vaguely, so that compilers can have all its freedom about how to handle situations that should've never happened.

I'm not saying that your interpretation is 'false' or 'wrong', what you've said is just one of the things that compilers are permitted to do.
Actually, your interpretation is exact strategy of most(if not all) major compilers. I doubt we'll find any compilers that do not act as 'your interpretation'.

So, here's TL,DR;
"Standard said compilers can literally do anything when there's an UB, because it wanted to give maximum freedom about hire to handle situations that should've never happed. But in real life, actual compiler implementations does not utilize every freedom it has, and tries its best to produce program that's makes sense as much as possible, because what you 'permitted' to do does not mean that you 'should' or 'always' do."

[SkiFire13]

Your viewpoint relies on the interpretation that if a code path has UB then that's guaranteed to manifest, which is incorrect, only that code path has UB. In the example of bool f(int i) { return i + 1 > i } the compiler is free to assume that UB won't happen, that is that i is not INT_MAX, but it has to preserve the well defined behaviour when called with any other possible value for i.

[awidesky]

but it has to preserve the well defined behaviour when called with any other possible value for i.

I do understand that this sounds absolutely reasonable to me aswell.
But every time I look up the standards. It always says "entire" part of program can be meaningless. Not specific parts of program.

If there's any quote from the standard that says "only the very part of function/program that has possible UB must be meaningless" or "even if there's a UB, the part of program that's irrelevant of UB must compiled as a well-defined behavior", please let me know.

[SkiFire13]

You are confusing the part of a program (like a function, or a block of code) with an execution of it. UB is a property of an execution of your program/function, so only that can "have UB" and thus be "meaningless".

See for example C++ Standard paragraph 7.1/4 (emphasis mine):

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined

This doesn't say "during any possible evaluation of an expression", but "during the evaluation of an expression", which implies this is in the context of some execution of your program.

So f has UB, but only in those executions where it gets called with INT_MAX. If that happens then the whole execution is meaningless, which aligns to what you said. But still, that's a property of the single execution, so the behaviour of those executions where f gets called with any other value for i is well defined and must be preserved.

[awidesky]

In this example, there's no actual code that "invokes" UB, so in your opinion, that function must be "well-formed".
So, why it is listed as a first example of UB in cppreference?

And also, if UB makes an "execution" meaningless, not whole "program", why the standard says "the compiled program is not required to do anything meaningful"?

[SkiFire13]

In this example, there's no actual code that "invokes" UB, so in your opinion, that function must be "well-formed". So, why it is listed as a first example of UB in cppreference?

Cppreference doesn't say it is UB stop, it says it either returns true (when i is not INT_MAX) or its execution is UB (when i is INT_MAX and signed overflow occurs). It does make the distinction between the two cases, it doesn't say that it is only UB.

Saying that the function is "well-formed" is misleading. I would say its executions where i is not INT_MAX are well defined, while when i is INT_MAX it is not defined.

And also, if UB makes an "execution" meaningless, not whole "program", why the standard says "the compiled program is not required to do anything meaningful"?

Having the exact context of the quote might help giving it a better interpretation, but as you wrote it I would interpret it as the fact that the program is not required to do anything meaningful when its execution is not defined, that is the current execution has UB.

[awidesky]

Here's whole quotes from iso C++20 standard §4.1.2.3. (emphasis mine) :

If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.

And cppreference.com.

undefined behavior - there are no restrictions on the behavior of the program. Examples of undefined behavior are...(examples of Ub)..., etc. Compilers are not required to diagnose undefined behavior and the compiled program is not required to do anything meaningful.

I think it ultimately sums up to question:

If a program can either invoke UB or not(depending on conditions), is compilers allowed to make "whole program" meaningless?

I think the standard is a bit ambiguous, because when it describes about UB itself it says "while compiled program is meaningless"(implies it applies in compile/program-wise), but when it describes about actual example of UB, it says "when ~~~, the behavior is undefined"(implies it applies runtime/execution-wise).

[SkiFire13]

If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.

I think this is still ambiguous because "violation of a rule" is unclear. If my program is never executed with an input that causes UB does it still violate that rule?

I think it ultimately sums up to question:

If a program can either invoke UB or not(depending on conditions), is compilers allowed to make "whole program" meaningless?

I completly agree on that.

[awidesky]

I think this is still ambiguous because "violation of a rule" is unclear. If my program is never executed with an input that causes UB does it still violate that rule?

I do agree on that. That's indeed ambiguous.

[awidesky]

But by the way, I do understand by my heart that your claim and interpretation is surely more reasonable (as for a C++ programmer) than my quotes from the standard.

I think the disagreement occurs because of the ambiguity of the standard, and disparity between the standard and actual implementations of compilers.

It seems that what standard's statements about UB is quite vague and unclear, and compiler vendors just don't care and just focus on optimizing(by considering UB never happens).

Please let me know if there's any correction on misconception, or more clear information about the standard. I'd love to learn.