Re: [PATCH] C undefined behavior fix

[Theodore Tso]

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