Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.snarked.org!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Newsgroups: comp.compilers
Subject: Re: Preprocessing ##
Date: Mon, 15 May 2017 11:28:46 +0200
Organization: Compilers Central
Lines: 30
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <17-05-004@comp.compilers>
References: <17-05-003@comp.compilers>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8339"; mail-complaints-to="abuse@iecc.com"
Keywords: C
Posted-Date: 15 May 2017 10:46:40 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:1871

Am 13.05.2017 um 08:49 schrieb Hans-Peter Diettrich:
> How is the C preprocessor assumed to handle the ## concatenation operator?
>
> In the Windows headers I found macros like
>   #define foo(x) bar(##baz(x))
> where an expansion into ... (baz ... doesn't make sense, because "(baz"
> is not a valid preprocessor token. Can somebody explain the meaning and
> handling of such constructs?

[John]
> [I would guess that some macro between ( and ## expanded to
> nothing.

The #define's leave no room for macros to the left of ##.

If, in above example, bar() were another macro, would the ## operator
stay literal part of the argument's token sequence?

E.g. with
   #define bar(z) some_prefix z
would foo(suffix) expand into
   some_prefix ##baz(suffix)
?

> Or it could just be one of those text editing errors. -John]

Not here. A comment before a couple of such #define's suggests, that
they are a workaround for the lack of variadic macros ("..." arguments).

DoDi