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."

Reply via email to