Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote: >> Can anyone set me strait on why, in the following code fragment >> >> int x(unsigned); >> >> struct alt_x { >> unsigned val; >> }; >> >> #define x alt_x >> #define alt_x(p) x(p+1) >> >> int test(struct x *p) { >> return x(p->val); >> } >> >> the function invoked in test() is alt_x (rather than x)? I would have >> expected that the preprocessor >> - finds that x is an object like macro, and replaces it with alt_x >> - finds that alt_x is a function-like macro and replaces it with x(...) >> - finds that again x is an object like macro, but recognizes that it >> already participated in expansion, so doesn't replace x by alt_x a >> second time. > > Why do you think that x has already participated in expansion? It > hasn't paricipated in the expansion of the function-like macro > alt_x, which is what is being considered, if I'm reading c99 right, > because no nested replacement of x occurred within the processing > of alt_x(). It's a different scan.
>From my reading of 6.10.3.4#1: After all parameters in the replacement list have been substituted and # and ## processing has taken place, all placemarker preprocessing tokens are removed. Then, the resulting preprocessing token sequence is rescanned, along with all subsequent preprocessing tokens of the source ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ file, for more macro names to replace. the rescanning of the expansion of x is still in progress when alt_x is expanded. Unfortunately, the examples at the end of 6.10.3 do not contain any of this kind. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."