Re: Preprocessing ##

Hans-Peter Diettrich <DrDiettrich1@aol.com.dmarc.email>
Fri, 2 Jun 2017 08:04:48 +0200

          From comp.compilers

Related articles
Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-13)
Re: Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-15)
Re: Preprocessing ## 686-678-9105@kylheku.com (Kaz Kylheku) (2017-05-15)
Re: Preprocessing ## gneuner2@comcast.net (George Neuner) (2017-05-15)
Re: Preprocessing ## DrDiettrich1@aol.com.dmarc.email (Hans-Peter Diettrich) (2017-06-02)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com.dmarc.email>
Newsgroups: comp.compilers
Date: Fri, 2 Jun 2017 08:04:48 +0200
Organization: Compilers Central
References: 17-05-003 17-05-006
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="11241"; mail-complaints-to="abuse@iecc.com"
Keywords: C, parse
Posted-Date: 05 Jun 2017 01:49:33 EDT

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


Post a followup to this message

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