Re: preprocessor/1565 (fwd)

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Bruno Haible <haible@ilog.fr>
Cc: neil@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
	kreckel@zino.physik.Uni-Mainz.DE, nobody@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Mon, 8 Jan 2001 18:26:47 +0000

 Hi Bruno,
 
 Your analysis is not correct.
 
 Bruno Haible wrote:-
 
 > I can't agree. ISO C 99, paragraph 6.10.3.4.2, and ISO/ANSI C++,
 > paragraph 16.3.4.2, talk about
 > 
 >    "this scan of the replacement list (not including the rest of the
 >     source file's preprocessing tokens".
 
 Sure, but this is not the relevant sentence.
 
 >      GEN_LF_OP2_AUX1
 > 
 > Here the "this scan" must stop because it needs more tokens. With the
 > next tokens from the file we get
 
 Yes.  But if I understand what you're trying to imply, I think you're
 misreading this.  Indeed, one of the examples in the standard refutes
 what you're saying.  Check out the example that reads
 
 #define t(a) a
 
 f(y+1) + f(f(z)) % t(t(g)(0) + t)(1);
                                ^^^^^
 
 You seem to be saying that that the t(1) that will result here should
 expand, because the (1) is coming from the rest of the file, after the
 scan of the outer t() has been exhausted.  The standard doesn't agree,
 as you can check, the example is shown to expand as as "t(1)" after
 full expansion.
 
 The words "(not including the rest of the source file's preprocessing
 tokens)" are referring to the second 'X' in examples like this:-
 
 #define e(n) 4 + n
 #define X e
 
 X(X)
 
 which expands to "4 + e", since we read the "(X)" from the rest of the
 source file and expand it, even though we are still expanding the
 original X.  You can check CPP gets this correct for yourself (it's in
 the test suite).
 
 The case in this PR is quite different - the 2nd instance of CONCAT
 comes from **the replacement list of macros being expanded**, not from
 the source file, and one of those macros that has not completed and is
 still undergoing expansion is CONCAT itself.
 
 Hence the bits that are important to expanding CONCAT here are the next two sentences:-
 
 "Furthermore, if any nested replacements encounter the name of the
 macro being replaced, it is not replaced"
 
 and even more so
 
 "These nonreplaced macro name preprocessing tokens are no longer
 available for further replacement even if they are later (re)examined
 in contexts in which that macro name preprocessing token would
 otherwise have been replaced"
 
 since this latter sentence refers to how, in the ISO example above, t
 pulls in the (1) from the rest of the source file, and is re-scanned
 as "t(1)" but not expanded.  In the same way, it is referring to the
 2nd CONCAT pulling in its parentheses.
 
 I hope I've persuaded you, if not we'll have to agree to disagree :-)
 
 I have no intention of reverting this behaviour.  The standard is
 quite clear; the new CPP is correct.  A fix for the end-user software
 is trivial, too: simply redefine a duplicate of the CONCAT macro with
 a different name, e.g. CONCAT2 or CONCAT_NESTED.
 
 Neil.