Re: [PATCH] C undefined behavior fix

[Linus Torvalds <torvalds at transmeta dot com>]

On Fri, 4 Jan 2002, Richard Henderson wrote:
>
> No.  You miss the point.
>
> Yes, it is very easy to adjust the code around the strcpy
> optimization to prevent this particular case from happening.
> I may do just that, but that doesn't solve the underlying
> dispute.

I actually think that would solve the underlying dispute, to a large
degree.

I think what people object to is optimizations that cannot be reasonably
explained in any logical manner. Most people expect the compiler to
compile the program pretty much the way the programmer asked for it, and
apply transformations that are legal and can improve code quality.

For example, people did say that "undefined behaviour" means that the
compiler is free to generate code to reformat the harddisk. That is true
from a technical standpoint, yet I think everybody agrees that a compiler
that does that is total crap.

The same goes for any optimization - if you can show that the generated
code has some reasonable behaviour behind it, people wouldn't complain.

The problem is that standards are inherently open to dispute. Some
optimizations push the envelope of what can be considered reasonable. For
example, I think your a/b array example can trivially be supported by the
C standard _not_ by using the "invalid index" example, but simply by
reading the sections about overlapping and aliasing rules.

The strcpy() optimization simply wasn't "reasonably expectable". The fact
is, C often _is_ used for low-level assembly by people who could write the
code in assembler, but who would be crazy to do so when there are tools to
help them do better.

When it comes to optimization, there are things that are "obvious", and
that will never generate any discussion at all, because they are faster
ways of getting the exact same result, with no question about it. Nobody
will ever fault a compiler for evaluating constant expressions at
compile-time rather than doing the math at run-time and getting the same
result. The two are indistinguishable from a result standpoint.

But optimizations that can change the value of an expression are slightly
different. They should make sense. You should be able to _explain_ them.
And the strcpy() optimization didn't follow that.

If you cannot explain the results, you end up having to argue about
word-weaseling in the standard, and people _will_ disagree on what the
damn thing means. Because standards aren't mathematically exact things.

		Linus