>>> Daniel Jacobowitz <[EMAIL PROTECTED]> 25.09.06 18:43 >>>
>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.
While, as Andreas also pointed out, the standard is a little vague in
some of what it tries to explain here, it is in my opinion clearly said
that the re-scanning restrictions are bound to the macro name, not
the fact that a function-like macro's expansion result is being
re-scanned. Hence, the re-scanning process of x has to be
considered still in progress while expanding alt_x, and consequently
x should not be subject to expansion anymore.
Jan
