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 01:40:06PM +0200, Momchil Velikov wrote:
>
> >>>>> "Aaron" == Aaron Lehmann <aaronl@vitelus.com> writes:
>
> Aaron> On Wed, Jan 02, 2002 at 01:03:25AM +0200, Momchil Velikov wrote:
> >> Thus
> >> strcpy (dst, "abcdef" + 2)
> >> gives
> >> memcpy (dst, "abcdef" + 2, 5)
>
> Aaron> IMHO gcc should not be touching these function calls, as they are not
> Aaron> made to a standard C library, and thus have different behaviors. I'm
> Aaron> suprised that gcc tries to optimize calls to these functions just
> Aaron> based on their names.
>
> IIRC, these identifiers are reserved by the C standard, thus the
> compiler is right to assume that they have standard behavior. And note
> that they DO have the standard behavior. It even doesn't matter if GCC
> is right to judge by the names in each and every case, it is right
> in _this_ case.

Right. The problem here is that this happens to be at a very early
point in the code (from arch/ppc/kernel/prom.c):
/*
* Note that prom_init() and anything called from prom_init() must
* use the RELOC/PTRRELOC macros to access any static data in
* memory, since the kernel may be running at an address that is
* different from the address that it was linked at.
* (Note that strings count as static variables.)
*/

Which is where the trouble comes in.

> Aaron> The gcc manpage mentions
>
> Aaron> -ffreestanding
> Aaron> Assert that compilation takes place in a freestanding
> Aaron> environment. This implies -fno-builtin. A freestand?
> Aaron> ing environment is one in which the standard library
> Aaron> may not exist, and program startup may not necessarily
> Aaron> be at "main". The most obvious example is an OS ker?
> Aaron> nel. This is equivalent to -fno-hosted.
>
> Aaron> Why is Linux not using this? It sounds very appropriate. The only
>
> Because it results in less optimization. I see no point in
> deliberately preventing the compiler from doing optimizations.

Right. There's only a very small number of files which _might_ be
effected by this optimization.

--
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.095 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site