cpp macro expansion bug

[Zack Weinberg]

On Wed, Apr 26, 2000 at 12:10:19PM -0500, Mumit Khan wrote:
> On Tue, 25 Apr 2000, Zack Weinberg wrote:
> > 
> > I don't see how we could possibly have got that with just _stdcall and
> > __stdcall defined, unless there was a bug in the code responsible for
> > finding the length of an identifier, and that hasn't changed recently.
> > 
> 
> Zack, 
> 
> Here's my complete testcase, which hopefully shows the problem I'm having.
> The problem seems to be related to gcc creating a new macro from __stdcall
> and adding trailing __ to it. Is that expected behaviour? 

Oh.  I get it now.  It's not cpp at all, it's the specs
transformations - that would be why I didn't see it.  I forgot that
*predefines has magic stuff done to it.

The problem is _stdcall.  That's in the user's name space.  When
*predefines is expanded by %P, it transforms macros in the user's
name space:

 %p     substitutes the standard macro predefinitions for the
        current target machine.  Use this when running cpp.
 %P     like %p, but puts `__' before and after the name of each macro.
        (Except macros that already have __.)
        This is for ANSI C.

which is not a great explanation.  It adds at most two underscores to
both ends of the macro, but if there's already one underscore it only
adds one more.  So _stdcall becomes __stdcall__.  __stdcall is already
in the implementation's name space and is untouched.

I would suggest that you dodge the problem by putting the definition
of _stdcall and __stdcall into CPP_SPEC instead of CPP_PREDEFINES,
where it will not be subject to %P's hackery. Something like

"-D__stdcall=__attribute__((__stdcall__)) \
 %{!ansi:-D_stdcall=__attribute__((__stdcall__)) \
 ..."

will serve the purpose.

zw

> ps: your email server is rejecting messages from my site
> (nanotech.wisc.edu) complaining that the sender domain can't be
> resolved. My message had to do with your patch to prefix.c, which
> I'll test out now that I can bootstrap win32 targets.

I think this must have been a transient glitch on your end, I can
resolve that domain just fine and messages have been getting through.

Thanks for testing the patch.