🚀 go-pugleaf

Consider the following code:

  #define a(x) b
  #define b(x) x

  a(a)(a)(a)

The macro replacement for a(a) results in b.
  First replacement buffer:  b       Remaining tokens:  (a)(a)
Inside the first replacement buffer, no further nested replacements
will recognize the macro name "a".  The name "a" is painted blue.

The first replacement buffer is rescanned not by itself, but along with
the rest of the source program's tokens.  "b(a)" also causes macro
replacement and becomes "a".
  Second replacement buffer:  a      Remaining tokens:  (a)

The second replacement buffer is rescanned not by itself, but along with
the rest of the source program's tokens.

The "a" in the second replacement buffer did not come from the first
replacement buffer.  It came from three of the remaining tokens which
were in the source file following the first replacement buffer.
Is this "a" part of a nested replacement?  Is it still painted blue?

Note that there are many "paths" that can be taken for a possible
macro name to travel from a preprocessor token (outside the replacement
buffer) to one that is inside the replacement buffer.  When do they
stop getting painted blue?  If either too early or too late, they cause
very surprising results.

The standard is very unclear on when the blue painting stops.  Could
someone please clarify?

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.