Re: [PATCH] C undefined behavior fix

Tom Rini
2002-01-02T15:59:22Z

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)