RE: preprocessor/4923: Concatenation appears to handle whitespace incorrectly

["Baum, Nathan I" <s0009525@chelt.ac.uk>]

The following reply was made to PR preprocessor/4923; it has been noted by GNATS.

From: "Baum, Nathan I" <s0009525@chelt.ac.uk>
To: 'Zack Weinberg' <zack@codesourcery.com>
Cc: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: RE: preprocessor/4923: Concatenation appears to handle whitespace
	 incorrectly
Date: Fri, 23 Nov 2001 19:32:29 -0000

 >From: 'Zack Weinberg' [mailto:zack@codesourcery.com]
 >Sent: 23 November 2001 18:51
 >To: Baum, Nathan I
 
 >> Would it break existing programs if ## were to concatenate the two tokens
 >> regardless (in some later version of gcc)? I'd imagine that no sensible
 >> program would rely upon undefined behaviour, so it shouldn't.
 Presumeably,
 >> it'd have to throw the two tokens away and rescan the newly created
 string,
 >> but that doesn't _seem_ like a major problem (I don't know how CPP
 handles
 >> these things internally, so it might be).
 >
 >It does, in fact, concatenate "the two tokens" in the textual output -
 >but the two tokens which get concatenated are ")" and "def".
 >Contrast
 >
 >#define a(x) FOO(abc) ## x
 >#define b(x) FOO(abc) x
 >
 >a(def)	-> FOO(abc)def
 >b(def)	-> FOO(abc) def
 
 Ah-ha. I grok that now. The problem isn't anything to do with ##, it's that
 the macro substitution puts in the whitespace, _after_ ## has done its
 stuff.
 
 >To do what you apparently want, when the ")" was the last character of
 >a macro invocation, it would have to remember that it had been pasted
 >after and apply the paste to the last token of the macro expansion.
 
 It looks like you could elect not to add any whitespace if the last
 character was a ")" (or some other single-character token ("(*/?:%^!")).
 Presumeably, that would never break a program. But, I've just checked the
 C++ specification for the preprocessor, and it appears that would be against
 the rules.
 
 >This would be a lot of work and frankly I don't see the point.  Show
 >me real code that desperately needs this functionality and I'll show
 >you how to fix it so it's standard conforming C.
 
 As far as I tell, I have no use for this feature, myself. Somebody wanted to
 know how they could do something like:
 
   #define  CONCAT(a,b) a ## b
   #define  STRCAT(a,b) #CONCAT(a,b)
   #include STRCAT(PREFIX, foobar.h)
 
 Naturally, this didn't work because of the macros' order of evaluation. On
 the other hand:
 
   #define STRCAT(a,b) #a #b
   #include STRCAT(PREFIX, foobar.h)
 
 I just tested that on gcc, to prove to myself that it wouldn't work, and it
 did. I assume, therefore, that he was using a non-gcc compiler (probably
 VC++, thinking about it), which wasn't happy about the multiple strings.
 
 The Standard says that the behaviour in this instance is undefined (oddly,
 it goes so far as to point out that by this time, strings wouldn't have been
 concatenated, but doesn't bother to specify that they should be in this
 situation.)