A token pasting corner case?

[David August <august at CS dot Princeton dot EDU>]

I am sure everyone is sick of hearing people complain about the "valid
preprocessing token" warning.  This is different, yet related.

Please consider the following:

#define DUDE STACK
#define FUNC2(val1, val2)  val1 HEY_ ## val2
#define FUNC1(val1, val2)  FUNC2(val1, ## val2)

FUNC1(I SAY, DUDE)


On egcs-2.91.66, this expands to:

  I SAY   HEY_DUDE


On 2.96, this expands to (and gives a warning of course):

I SAY HEY_STACK


Now, here's my dilemma.  The machine code emulator we are developing
works by creating gcc-extended C code from assembly files. (It
supports IA-64 asm and a few others.)  By using a macro for each asm
instruction, we can insert probes into the code to collect profile
statistics, drive our simulator, etc.  We make HEAVY use of labels as
values, double word integers, variable length macros, pastings, etc.
Basically, we are happily stuck with gcc, but unhappily stuck with
versions < 2.96 because of the above discrepancy.

In order to eliminate redundant code macros, most of the code does
something like the above code example and assumes the egcs-2.91.66
behavior.  (I can give more details or share the code if anyone cares
about why this is necessary - it's related to treating immediate and
register operands/arguments differently.)  Essentially, we need to
delay the expansion of DUDE to STACK until the lowest level by using
the pasting:

#define FUNC1(val1, val2)  FUNC2(val1, ## val2)

which seems to do the trick.  It is really nice to be able to delay
the expansion (or final pasting) of DUDE until the lowest level.  I
realize this is does not generate a valid token and is probably even
undefined behavior.  However, things get really ugly without some way
to delay the expansion.

Here is my question: Is there any good way to prevent this expansion
in 2.96+?  If not, why not?  The manual seems to imply that this is a
very common thing to want to do.  It suggests tricks for expressions
and some statements, but not other argument types.  Can a more general
solution be integrated into the preprocessor?  Perhaps a "do not
expand this argument" operator?

Thank you in advance for your help.

David


P.S. The code generated is quite unlike code a human would write.  This
stresses gcc in some interesting ways - but that (Region-Based
Compilation) is a topic for another day.

-- 
Prof. David August                        Department of Computer Science
august@cs.princeton.edu                   Princeton University
http://www.cs.princeton.edu/~august       (609) 258-2085