Re: Preprocessing ##

Am 15.05.2017 um 17:31 schrieb George Neuner:
> On Sat, 13 May 2017 08:49:36 +0200, Hans-Peter Diettrich
> <DrDiettrich1@netscape.net> wrote:
>
>> How is the C preprocessor assumed to handle the ## concatenation operator?
>
> It concatenate tokens *prior* to expansion. If the token references a
> parameter of the current macro, the (text of the) parameter is
> substituted, otherwise the token is simply copied.


In a newer draft I found the constraint, that ## is an operator only if
present in the replacement list (macro body), not from an argument.


>> In the Windows headers I found macros like
>> #define foo(x) bar(##baz(x))


Here the constraint is violated, ## is part of the argument and thus not
recognized as a preprocessor operator.




>> [I would guess that some macro between ( and ## expanded to
>> nothing. Or it could just be one of those text editing errors. -John]
>
> I think John probably is correct that you've found typos. If it were
> the result of a macro substitution, you would see it only in the
> output of the preprocessor - it would not be visible in an input
> header file.


In the meantime I guess that this construct is a creative use of the
preprocessor, when *also* used for some other postprocessor. The C
compiler may never see the ## if bar(x) has an empty definition, with
the argument unused. This seems to be the case with above example,
unless a project or tool adds global definitions which result in a
different definition of bar(x).


The standard also includes an example
      #define hash_hash # ## #
which expands into a new ## token, which *is not* the ## operator. This
may or may not mean that ## is recognized and handled as a preprocessor
operator *only if* it occurs in the replacement list (body) of a macro
definition. Such a token is not accepted subsequently by a C compiler,
but may be recognized by some other tool. Likewise the standard requires
that a # operator must be followed by a macro argument, else it is not
recognized as a preprocessor operator. This signals to me that the
preprocessor is allowed to output token sequences which are not valid C
code, but may be valid when processed by some other tool.




> Moreover, although I'm not 100% certain, I believe the preprocessor
> does not substitute inside (it's own) preprocessor definitions, but
> rather only substitutes into C code.


Right, immediate evaluation of # ## #, as a constant expression during
macro definition, would result in a new ## token inside the replacement
list, which would be recognized as another ## operator during a
subsequent macro expansion. This were not the behaviour indicated by the
description of above example.


Thanks for your comments, without which I e.g. had guessed that constant
expression evaluation were allowed during macro definition.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.