Messages in this thread | | | Date | Wed, 2 Jan 2002 08:59:00 -0700 | From | Tom Rini <> | Subject | Re: [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/
| |