Re: [PATCH] C undefined behavior fix

[Florian Weimer <fw at deneb dot enyo dot de>]

Linus Torvalds <torvalds@transmeta.com> writes:

> In article <20020104121403.D7262F3123@nile.gnat.com> you write:
>>
>>We can't avoid people writing wrong code, but we can avoid debate as to
>>whether the code is right or wrong :-)
>
> However, gcc clearly does the wrong thing with strcpy() right now.

The strcpy() problem is really just a symptom.

> And the gcc people claim it is undefined behaviour, which is not
> actually true if you just add two casts (which won't actually change the
> low-level RTL at all).

The code presented by Momchil Velikov *is* *clearly* *undefined*. And
I think GCC is not obliged to follow your expectation even if there
are additional casts.

> It is implementation-defined, and documented by gcc to do the
> bit-wise arithmetic

No, there is an exception (I quote from an outdated checkout, so this
hasn't just been committed to the repository, although it fits us so
neatly):

| 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.

The message to programmers is extremely clear: don't do that, or it
will probably hurt you.

There might be some exercises for language lawyers lurking here (there
are several ways to make this fit into the gaps in section 6.3.2.3).

> that was exactly what the linker people expected.

We all know that nobody reads GCC documentation.

> The gcc-3 optimization is _bogus_ as per the C standard,

I'm quite sure it isn't.  The gaps of 6.3.2.3 can be used to justify
the cited constraint.

Of course, the C standard does not properly formulate what
"implementation-defined behavior" and the documentation requirement
associated with it actually mean, so we have plenty of room anyway.

> and has to be disabled at least for the case where the pointer was
> cast to an integer.

Please show us the proof.