Re: patch advice needed: macro expansion for #pragmas

[Paul Rubin <phr-2006 at nightsong dot com>]

    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.

Yes, I didn't see how to use that given that the client needs the
first identifier expanded.  I'd been working with 4.0.2 but I see that
do_pragma has changed somewhat in the current SVN so I'll re-do my
patch for the current revision.

    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.

I was about to do it the other way:

  1. With expansion disabled, read the first identifier
  2. If the identifier names a pragma namespace that says "don't
     expand" (or alternatively, if the identifier is specifically "STDC"),
     then keep processing with no expansion.
  3. Otherwise: enable expansion, push back the identifier, and start over.

The above would (in my version) only be done if --expand-pragmas were
enabled.  Your method also sounds ok to me.  Let me know what you
think.

    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 :)

I defer to the gcc experts about whether it's ok to do
unconditionally.  It's currently documented behavior that pragmas are
never expanded, so doing the above unconditionally is an incompatible
change from the documented behavior, which suggests a conditional.  On
the other hand, it's quite plausible that nobody currently relies on
the currently documented behavior, so it's perhaps ok to change if the
change is announced in release notes.  I think my client is going to
stay with 4.0.2 (plus patched libcpp) for now, so will be nonstandard
either way.

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

Nice meeting you too ;-).

--Paul