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