Re: [PATCH] C undefined behavior fix

[Linus Torvalds <torvalds at transmeta dot com>]

On Fri, 4 Jan 2002, Richard Henderson wrote:
>
> The entire description is
>
>   3.4.1 implementation-defined behavior
>   unspecified behavior where each implementation documents how
>   the choice is made.

Right. But note how there _must_ be a choice. That's the part that says
it's not "undefined", and is the only real difference between undefined
and implementation-defined, wouldn't you agree?

Ie an implementation can NOT just say "our implementation-defined
behaviour for X is undefined behaviour". That's not documenting anything.

> and
>   J.3 Implementation-defined behavior
>   A conforming implementation is required to document its choice
>   of behavior in each of the areas listed in this subclause.

But gcc does _not_ document its choices. So gcc isn't conforming to the
standard.

> GCC's choice of behaviour is to not cater to smart-asses who are
> trying weasel-word their way around 6.5.6/8.

I don't think it's weasel-wording. It clearly says that pointer arithmetic
is undefined, and that pointer casting is implementation-defined. That's a
hint to the optimizer: if the programmer does pointer arithmetic, the
optimizer can be more relaxed than if the programmer does a pointer cast.

I realize that gcc internally doesn't know about the distinction after a
certain point, but if gcc doesn't know, then gcc has to assume the worst.

So the strcpy() optimization is perfectly valid on a tree-level if you
have pointer arithmetic (when you have the type casting information), but
would not be valid on an RTL level once you've lost the distinction
between pointers and integers.

		Linus