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


Paul Rubin wrote:
> A consulting client of mine has asked me to make a cpp patch that
> causes GCC to optionally expand preprocessor macros in #pragmas.  He
> is trying to migrate a huge codebase from Microsoft C to GCC.  The
> code has a lot of pragmas like
>
>    #pragma FOO
>
> where FOO is a symbol created by a #define statement elsewhere in the
> program.

As others have said, I think this would be a good feature to add.

> C99 specifies certain standard pragmas and further specifies that
> macros should NOT be expanded for those pragmas.  What happens with
> other pragmas is up to the compiler.  GCC handles it by not expanding
> macros for any pragmas.  It would still be C99 conformant if it didn't
> expand the C99-standard pragmas but expanded all other pragmas.
> Microsoft C apparently does expand those pragmas, and the client's
> program relies on the expansion taking place.
>
> I've made a patch that adds a command line option ("--expand-pragmas")
> that, when activated, disables the inhibition of pragma macro
> expansion in libcpp/directives.c:do_pragma().  That of course means
> ALL pragmas get expanded, including the C99 standard pragmas, so the
> patch is not C99-conformant.  I'd been planning to add some additional
> logic to distinguish between the C99 pragmas and other pragmas, and
> expand only the C99 pragmas.  But I see there's an internal table of
> pragmas, which don't get expanded (IIRC there's a flag in the table
> entry; I don't have the code in front of me right now).  So I'm
> thinking of just adding the C99 pragmas to that table.  Is that a
> reasonable approach?

I'm not sure whether you're looking at the latest sources, but
we've recently added the capability to macro-expand everything
*after* the leading identifier for designated #pragmas; this is for
compatibility with Sun C and others.  There is also the capability to
allow macro-expansion of the *second* identifier in a #pragma for
designated #pragma namespaces.  Whatever you do should build on that.

Now, from your description, neither of these things will satisfy
your client, who wants the leading identifier expanded.  Would your
client be happy with the following semantic: 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.  So, the FOO
in #pragma FOO would be macroexpanded, #pragma STDC whatever would
not, even if STDC has been #define-d above, and you could use a
#define that expanded to a STDC pragma if you really wanted.  Either
way, macro expansion of subsequent tokens is as specified when the
pragma was registered. 

I suggest this somewhat convoluted semantic because, if it works
for the people who want this feature, it should be okay to do it
unconditionally, which eliminates the need for a new command line
option.  I like to avoid -funbreak-my-program whenever possible :)

> --Paul Rubin
> (original author of cccp.c if that matters)

Pleased to make your acquaintance after so many years working with
descendants of your code.

zw


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