Re: [PATCH] C undefined behavior fix

From: Tom Rini (trini@kernel.crashing.org)
Date: Wed Jan 02 2002 - 10:59:00 EST


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/



This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:17 EST