This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
In article <20020102171224.D10659@redhat.com> you write:
>On Wed, Jan 02, 2002 at 05:16:05PM -0700, Tom Rini wrote:
>> > Ignore strcpy. Yes, that's what visibly causing a failure here,
>> > but the bug is in the funny pointer arithmetic. Leave that in
>> > there and the compiler _will_ bite your ass sooner or later.
>>
>> Er, which part of the 'funny pointer arithmetic'?
>
>What's currently inside RELOC.
I think you're wrong.
The thing is, pointer expressions outside the area may be "undefined
behaviour", but the same is NOT true if you cast the thing to an
unsigned long or similar. At that point it is _implementation_ defined
what the result is, and gcc has clear guidelines on what the
int->pointer conversion is.
So the linker thing could trivially just change the expression with two
casts, and suddenly all the "undefined" arguments go out the window. It
is purely an implementation-defined thing at that point, and the gcc
implementation defined behaviour for integer to pointer conversion is
the one the linker source code expects. If it doesn't get it, then
that's a gcc bug. Plain and simple.
And when you add the two casts, gcc will _still_ do the same bogus
optimization, at which point the gcc excuse of "undefined behaviour" no
longer holds any water at all.
Get rid of the optimization. It's only valid of the offset is within
the string, so the built-in "strcpy()" should explicitly test for that
validity, because otherwise gcc _will_ create invalid code.
See 6.3.2.3, about the implementation-defined aspect of this if you
don't believe me.
Linus