This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Momchil Velikov <velco at fadata dot bg>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, linux-kernel at vger dot kernel dot org, gcc at gcc dot gnu dot org, linuxppc-dev at lists dot linuxppc dot org
- Date: Wed, 2 Jan 2002 08:11:39 -0500
- Subject: Re: [PATCH] C undefined behavior fix
- References: <87g05py8qq.fsf@fadata.bg> <87y9jh3v27.fsf@deneb.enyo.de> <874rm5yqzr.fsf@fadata.bg>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jan 02, 2002 at 12:41:28PM +0200, Momchil Velikov wrote:
> >>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:
>
> Florian> Momchil Velikov <velco@fadata.bg> 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.
>
> 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.
Jakub