Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: Kaz Kylheku <686-678-9105@kylheku.com>
Newsgroups: comp.compilers
Subject: Re: Preprocessing ##
Date: Mon, 15 May 2017 13:41:08 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 19
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <17-05-005@comp.compilers>
References: <17-05-003@comp.compilers>
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8665"; mail-complaints-to="abuse@iecc.com"
Keywords: C, comment
Posted-Date: 15 May 2017 10:47:09 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:1872

On 2017-05-13, Hans-Peter Diettrich <DrDiettrich1@netscape.net> wrote:
> 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?

According to ISO C, if the result of the ## operator is an invalid
token, the behavior is undefined.

If you're making a compiler which will have to handle the unmodified
header files from Microsoft platform development kits for Windows, you
have little choice but to implement compatible preprocessing, which
handles whatever constructs occur, in the same way.

In other words, the actual meaning here is "whatever Visual C does".
[Ugh.  But I have to agree. -John]