This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Theodore Tso <tytso at mit dot edu>
- To: mike stump <mrs at windriver dot com>
- Cc: gdr at codesourcery dot com, paulus at samba dot org, dewar at gnat dot com, gcc at gcc dot gnu dot org,linux-kernel at vger dot kernel dot org, trini at kernel dot crashing dot org,velco at fadata dot bg
- Date: Mon, 7 Jan 2002 16:21:12 -0500
- Subject: Re: [PATCH] C undefined behavior fix
- References: <200201071936.LAA12038@kankakee.wrs.com>
On Mon, Jan 07, 2002 at 11:36:45AM -0800, mike stump wrote:
> #define hide(x) ({ void *vp = x; asm ("" : "+r" (vp)); vp; })
>
> > My main problem with this is that it doesn't actually solve the
> > problem AFAICS.
>
> It does for now. It will for the next 10 years, my guess. volatile
> will solve it longer, at some performance penalty, if you prefer.
>
> > Dereferencing x is still undefined according to the rules in the gcc
> > manual.
>
> ? So what? Pragmatically, for now, it does what the user wants. By
> the time we break it, we'll probably have enough intelligence in the
> compiler to figure out what they were doing and still not break it.
Why not fix the problem by adding some a GCC-specific construct which
allows the programmer to say, I know what I'm doing; don't make any
assumptions about this pointer. (i.e., "my gun, my foot, my rules").
I.e., something like this:
#hide(x) (__builtin_gcc_this_is_not_the_pointer_you_were_looking_for__(x))
(or __builtin_gcc_jedi_mind_trick__, or pick some other name if you
like :-)
That way, you don't have to posit adding AI to GCC in the future to be
able to intuit what was going on, and programmers can take comfort in
the fact the behaviour is will defined, and won't get screwed up when
in GCC 4.0, the compiler writers decide that "Gee, most people write
inefficient assembly; so let's go and reverse engineering people's
__asm__ statements in an effort to 'optimize' their code".
- Ted