On 26 September 2006 08:43, Jan Beulich wrote:
>>>> 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.
> 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.
Actually, it's because cpp has a special exception for recursive macros,
isn't it? After
>>> #define x alt_x
the preprocessor token "x" is an object-like macro standing for "alt_x", so
when we get to
>>> #define alt_x(p) x(p+1)
what the preprocessor sees after the first round of expansion is
#define alt_x(p) alt_x(p+1)
at which point cpp's "No recursive expansion" rule kicks in and all further
expansion stops.
" If the expansion of a macro contains its own name, either directly or
via intermediate macros, it is not expanded again when the expansion is
examined for more macros. This prevents infinite recursion. *Note
Self-Referential Macros::, for the precise details. "
cheers,
DaveK
--
Can't think of a witty .sigline today....
