Re: [PATCH] C undefined behavior fix

[Linus Torvalds <torvalds at transmeta dot com>]

On Fri, 4 Jan 2002, Richard Henderson wrote:
>
> In particular,
>
>   When casting from pointer to integer and back again, the resulting
>   pointer must reference the same object as the original pointer, otherwise
>   the behavior is undefined. That is, one may not use integer arithmetic
>   to avoid the undefined behavior of pointer arithmetic as proscribed
>   in 6.5.6/8.

To paraphrase:
 Two implementation-defines does not make a undefine.

Two wrongs do not make a right.

> The primary reason for this restriction is that pointer arithmetic
> becomes integer arithmetic the moment it enters rtl, at which point
> we can't tell the difference between them anymore, and if we intend
> to do any sort of alias analysis, we must be able to assume that
> some sort of silliness isn't happening.

But that is a compiler implementation issue, and does not allow the
compiler to change the rules of what is implementation-defined and what is
not.

If you have an implementation-defined operation for turning a pointer into
an integer (and you must have such a rule as per the standard), you cannot
just make it undefined by claiming it is so when somebody does something
else with it.

Yes, gcc forgets about "what is a pointer" when it gets to the RTL layer.
Yes, that means that alias analysis at that level simply is not valid. But
no, that does not mean that you can avoid the standard.

> And that is exactly what's going on here, except that instead of a
> user-declared array variable we have a string literal.

You want that to be true, but you wanting to make it so doesn't make it
so. The standard has no place that says that "implementation defined
behaviour may be undefined". It says that implementation-defined means
that the implementation has to document how it does something. It does NOT
allow for saying that the implementation can turn something into
"undefined".

		Linus