This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch advice needed: macro expansion for #pragmas


On Tue, Feb 14, 2006 at 01:18:33AM -0000, Paul Rubin wrote:
>     cpplib first tries to process the pragma with no macro expansion
>     of the leading identifier.  If there is no registered pragma with
>     that name, the leading identifier is macro-expanded, and cpplib
>     tries again....
> 
>     My version changes behavior only in the case where the first
>     identifier on the #pragma line is *not* recognized; thus, the only
>     #pragma-s whose behavior changes are currently not doing anything
>     useful.  I'm happy with making that kind of behavior change
>     without any option to control it.
> 
> I have a slight reservation about this, which is suppose FOO is not
> recognized.  Therefore it gets macro-expanded.  Then in some later
> version of the preprocessor, FOO becomes a registered pragma and the
> expansion quietly stops and the code breaks.

Hmm, yes, that could be a problem.  We could sidestep it by making a
policy decision that we would add no more pragmas with expansion
suppressed, but I don't think that would be a good idea - we tend to
add pragmas only by importing external specifications, and they might
insist on no-expansion behavior.

There may not be a perfect solution here, which would argue for the
command line option, sigh.

> Or, FOO expands to BAR,
> and BAR becomes a registered pragma, which would prevent further macro
> processing.

That wouldn't happen, though, because macro processing on FOO would run
to completion in the usual manner before we looked up pragma handlers
again, so BAR would always be expanded too.

> Having a command line option saying "definitely expand" (except for
> specific pragmas or maybe just for STDC pragmas) would sidestep this,
> I think.  It would also let GCC more closely simulate the behavior of
> Microsoft C, making porting MS C programs to GCC easier.

Well, if we're going for exact compatibility with MS C, don't we want
to ignore C99 altogether and just expand everything on a #pragma line?
(Which would, then, definitely be a new command line option.)

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]