lkml.org 
[lkml]   [2002]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] C undefined behavior fix
On Wed, Jan 02, 2002 at 08:54:08AM +0200, Momchil Velikov wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
>
> Tom> On Wed, Jan 02, 2002 at 01:03:25AM +0200, Momchil Velikov wrote:
>
> >> The appended patch fix incorrect code, which interferes badly with
> >> optimizations in GCC 3.0.4 and GCC 3.1.
> >>
> >> The GCC tries to replace the strcpy from a constant string source with
> >> a memcpy, since the length is know at compile time.
>
> Tom> Check the linuxppc-dev archives, but this has been discussed before, and
> Tom> it came down to a few things.
>
> Well, you may discuss it again, but this time after actually reading
> the C standard:
>
> "6.3.6 Additive operators
> ...
>
> 9 Unless both the pointer operand and the result point to
> elements of the same array object, or the pointer operand
> points one past the last element of an array object and the
> result points to an element of the same array object, the
> behavior is undefined if the result is used as an operand of a
> unary * operator that is actually evaluated."
>
> Tom> 1) gcc shouldn't be making this optimization, and Paulus (who wrote the
> Tom> code) disliked this new feature.
>
> Why gcc shouldn't be making some optimization. Because a particular
> person doesn't like it or ? What kind of statement is that anyway ?

Well, Paulus wrote 'strcpy' not 'memcpy', so why does gcc get to assume
it's safe to change it? In this case it's certainly not.

> Tom> As a subnote, what you sent was sent
> Tom> to Linus with a comment about working around a gcc-3.0 bug/feature, and
> Tom> was rejected because of this.
>
> It is not a workaround, it is a fix to an invalid code, which gets
> triggered by particular optimization.

By a particular optimization that's not present before gcc-3.0, and
happens to break things under some conditions, as you've seen.

> Tom> 2) We could modify the RELOC macro, and not have this problem. The
> Tom> patch was posted, but not acted upon.
>
> Although all uses of the RELOC macro violate the standard, this kind
> of pointer arithmetic is far too common and usually produces the
> expected behavior, thus it make sense to optimize the cases where ut
> breaks

And for the case it breaks?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.207 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site