[Zlib-devel] zlib 1.2.6 released

[jbowler at acm.org]

From: Mark Adler
>I was wondering if a #define using its own name in the definition would pose a problem

In this case that's not what stops it: the #define of gzgetc is a "function-like" macro (3.8.3 line 24) and is only expanded if the name is followed by "(" (3.8.3 line 34).  Jan's patch makes the next pp-token an ")" so no expansion occurs.  In fact it wouldn't anyway (i.e it would be ok to do gzgetc( in place of (gzgetc)() because macros are not expanded when encountered during their own expansion (3.8.3.4, line 5):

#define x x
x

is fine; during expansion when "x" is encountered the second time (recursively) it is not expanded.  Still, putting the gzgetc in () makes the whole thing several orders of magnitude clearer.

>It's pretty clear about it: "The preprocessing tokens within a preprocessing
>directive are not subject to macro expansion unless otherwise stated."
> (And it's not otherwise stated for #define.)

I think it's true that the convoluted set of rules can be re-stated as, simply, "macro expansion doesn't happen until the result is used."   Thus the following is a pair of mutually recursive definitions:

#define x y
#define y x
x
y

and is resolved because a given macro is only expanded once (so x -> y -> x, then stops, and y -> x -> y and stops.)

It gets complicated (very complicated) with macro arguments because they get expanded before they get substituted in the body of the macro *unless* the formal parameter in the macro is itself the subject of a # or ## directive, when the original unsubstituted tokens are used.  So:

#define one 1
#define zero 0
#define cat(a,b) a ## b
#define foo(x,y) cat(x,y)
cat(one,zero)
foo(one,zero)

gives "onezero" then "10".  Personally I find this extremely non-intuitive.

John Bowler <jbowler at acm.org>