Re: [PATCH] C undefined behavior fix

[Tom Rini]

On Wed, Jan 02, 2002 at 08:11:39AM -0500, Jakub Jelinek wrote:
> 
> On Wed, Jan 02, 2002 at 12:41:28PM +0200, Momchil Velikov wrote:
> > >>>>> "Florian" == Florian Weimer <[e-mail]> writes:
> >
> > Florian> Momchil Velikov <[e-mail]> writes:
> > >> -		strcpy(namep, RELOC("linux,phandle"));
> > >> +		memcpy (namep, RELOC("linux,phandle"), sizeof("linux,phandle"));
> >
> > Florian> Doesn't this still trigger undefined behavior, as far as the C
> > Florian> standard is concerned?  It's probably a better idea to fix the linker,
> > Florian> so that it performs proper relocation.

This has been suggested too.  And if someone implemements this in the
2.5.x timeframe it might even go in (as long as it works w/ gcc-2.95.x,
which really should be doable).

> > Well, strictly speaking it _is_ undefined, however adding/subtracting
> > __PAGE_OFFSET is far too common operation and one can resonably expect
> > to get away with it in the _vast_ majority of cases. IMHO, it is
> > better to fix the particular case, which triggers the undefined
> > behaviour, as these cases are bound to be _very_ rare.
> 
> IMHO the best thing is to change the RELOC macro, so that gcc cannot optimize
> this.
> E.g.:
> -#define PTRRELOC(x)     ((typeof(x))((unsigned long)(x) + offset))
> +#define PTRRELOC(x)     ({ unsigned long __x = (unsigned long)(x);	\
> 			    asm ("" : "=r" (__x) : "0" (__x));		\
> 			    (typeof(x))(__x + offset); })
> This way gcc cannot assume anything about it.

This is what Franz Sirl suggested awhile back, which should work, but
doesn't look too nice.  If gcc-3.0.x is going to be expected to produce a
working kernel on all arches, I suppose this is the best fix for now.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/