pacing of the subsequent
token is special.  The preprocessor inserts padding tokens in front of
every macro expansion and expanded macro argument.  These point to a
"source token" from which the subsequent real token should inherit its
spacing.  In the above example, the source tokens are 'add' in the macro
invocation, and 'y' and 'z' in the macro replacement list, respectively.

   It is quite easy to get multiple padding tokens in a row, for example
if a macro's first replacement token expands straight into another
macro.

     #define foo bar
     #define bar baz
     [foo]
             ==> [baz]

   Here, two padding tokens are generated with sources the 'foo' token
between the brackets, and the 'bar' token from foo's replacement list,
respectively.  Clearly the first padding token is the one to use, so the
output code should contain a rule that the first padding token in a
sequence is the one that matters.

   But what if a macro expansion is left?  Adjusting the above example
slightly:

     #define foo bar
     #define bar EMPTY baz
     #define EMPTY
     [foo] EMPTY;
             ==> [ baz] ;

   As shown, now there should be a space before 'baz' and the semicolon
in the output.

   The rules we decided above fail for 'baz': we generate three padding
tokens, one per macro invocation, before the token 'baz'.  We would then
have it take its spacing from the first of these, which carries source
token 'foo' with no leading space.

   It is vital that cpplib get spacing correct in these examples since
any of these macro expansions could be stringized, where spacing
matters.

   So, this demonstrates that not just entering macro and argument
expansions, but leaving them requires special handling too.  I made
cpplib insert a padding token with a 'NULL' source token when leaving
macro expansions, as well as after each replaced argument in a macro's
replacement list.  It also inserts appropriate padding tokens on either
side of tokens created by the '#' and '##' operators.  I expanded the
rule so that, if we see a padding token with a 'NULL' source token,
_and_ that source token has no leading space, then we behave as if we
have seen no padding tokens at all.  A quick check shows this rule will
then get the above example correct as well.

   Now a relationship with paste avoidance is apparent: we have to be
careful about paste avoidance in exactly the same locations we have
padding tokens in order to get white space correct.  This makes
implementation of paste avoidance easy: wherever the stand-alone
preprocessor is fixing up spacing because of padding tokens, and it
turns out that no space is needed, it has to take the extra step to
check that a space is not needed after all to avoid an accidental paste.
The function 'cpp_avoid_paste' advises whether a space is required
between two consecutive tokens.  To avoid excessive spacing, it tries
hard to only require a space if one is likely to be necessary, but for
reasons of efficiency it is slightly conservative and might recommend a
space where one is not strictly needed.