Undefined behavior in C is a reading error

> Of course an implementation can do anything it likes, including defining the behavior. That's one of the infinitely many ways of handling it -- precisely because it's undefined behavior.

An implementation can do whatever it likes within the proscribed bounds the standard provides for reacting to "undefined behavior", and conversely whatever the implementation chooses to do within those bounds is consistent with the standard.

Which, again, is the entire point of this: "the loop iterates exactly 16 times" is a standards-conforming interpretation of the code in question. There's nothing outside the standard or non-standard about that. That is, in fact, exactly what the standard says that it is allowed to mean.

> I'm not using "undefined behavior" as the English two-word phrase. I'm using the technical term as it's defined by the ISO C standard.

So am I. Unlike you, I'm merely taking into account the part of the standard that says "NOTE: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results..." and acknowledging that things that do so are standards-conforming.

> You seemed to be suggesting that "ignoring the situation completely" would result in the loop iterating exactly 16 tyimes.

I'm merely reiterating what the standard says: that the case in which the loop guard overflows can be ignored, allowing an implementation to conclude that the loop iterates exactly sixteen times in all scenarios it is required to consider.

All you seem to be doing here is reiterating, over and over again, "the standard says the behavior of the loop is undefined" to argue that the loop has no meaning, while ignoring that a different page of the same standard actual gives an allowable range of meanings to what it means for "behavior to be undefined", and that therefore anyone of those meanings is, in fact, precisely within the bounds of the standard.

We can validly say that the standard says "for (int i=param; i < param + 16; i++)" means "iterate 16 times always". We can validly say that the standard says "for (int i=param; i < param + 16; i++)" means "launch angband when param + 16 exceeds MAX_INT". Both are true statements.

To me the real problem is that compilers these days do too much. Nobody asked for these optimizations, if you want optimized code, use C++, or Rust, or whatever other "modern" language that has higher level constructs and thus can optimize the code better.

The reason to use C is to have an "high level assembler", and there is no reason to use C if I can't rely on the output of the compiler, and if the compiler eliminates some code that I write. We all know that happens when a signed integer overflows, we all know that most architectures are little endian, etc.

Even if something is "undefined behaviour" for the standard, it usually has some well defined behaviour on the platform that you are targeting.

Unfortunately, for these reasons gcc is dangerous to use, it's not a problem of desktop application (if it crashes, who cares), but I talk about critical systems. It would be unacceptable if a machine ends up killing someone because at gcc they though that they could remove a check that they thought it was useless. And so you have to spend thousand of $ just to get reliable compilers that doesn't do silly optimizations.

I think that they should make a sort of "gcc lite" that does exactly what (at least to me) a C compiler has to do: translate the code from C to assembly, without changing the semantic of the code. If there is an undefined behaviour that behaviour will be translated to the assembly code and you will let the processor to deal with it.

Also, we talk about optimizations that could be made by exploiting undefined behaviour, fine, but also the programmer usually optimizes exploiting the same undefined behaviours by hand.

This is addressed quite thoroughly in the thread that I linked. It is generally impossible to determine whether your code has a bug, and you cannot possibly be responsible for every bit of code that your code may happen to touch, but even if you could, mistakes and bad practices will happen. Practically speaking, it does not matter if you can find a way to displace blame onto the writer of the code. Placing blame is not how one minimizes harm. Maybe we have different definitions of pragmatism in our heads.

I would also say that leaving such a common occurrence as integer overflow as undefined behavior rather than to consider that it practically always has platform as implementation specific behavior doesn't make much sense. I mean, it does always have platform specific implementation, right? Does that not exclude it from the definition of undefined behavior? Genuinely curious.

The downvotes on my previous comments tell me this sort of thinking is endemic. I suddenly have more insight into the concern people have about software development as a field.

It’s not useless. The assumption is not false if the program doesn’t have undefined behavior. The assumption allows the code to be a few times faster. To disallow this assumption would inhibit these optimizations.

To me ignore the situation completely with unpredictable results would mean: the compiler generates an assembly that could not be correct, and then the behaviour of the program is determined by what the processor does.

Doing something like removing checks is not ignoring the situation: is acting in some particular way when undefined behaviour is detected.

And it has neither unpredictable results: it specifies what happens, since these checks are added systematically.

I don't see anywhere in the standard that the compilers are free to change at their choice the semantic of the program if undefined behaviour is detected. Rather undefined means to me that the compiler generates code where the result cannot be known because it will depend on external factors (basically the hardware implementation).