Macro replacement in argument substitution

Doug Gwyn gwyn at smoke.BRL.MIL
Thu Nov 9 17:01:44 AEST 1989


In article <1989Nov8.222632.699 at algor2.algorists.com> jeffrey at algor2.ALGORISTS.COM (Jeffrey Kegler) writes:
>Section 3.8.3.4 protects only "the name of the macro being replaced"
>from being replaced on a second scan.  This pretty clearly supports
>Diamond's interpretation.  Even if we try to interpret the parameters
>of a function-like macro as "macros", the use of the singular in the
>dpANS makes it clear the writer of that section did not have
>parameters of function-like macros in mind.

You entirely miss the point.  In the argument to the function-like
macro in the example under discussion (putc(b)), there occurred an
invocation of the object-like macro "b".  There is no question
whatsoever that this invocation of "b" is itself macro-expanded
before being plopped into the function-like macro's replacement
buffer.  The question was whether or not the blue paint applied to
"b" during that initial expansion would still be in effect during
the later rescan of the function-like macro replacement buffer.

>Usually, we would prefer the wording of the text over an example.

The text does say that the paint persists, but it could be misread
as allowing the paint to evaporate immediately after the argument
macro expansion was complete.  It could also reasonably be read as
saying what Dave and the example claim it says, and in some ways
it is a simpler interpretation than the one Norman and I initially
applied.

>The choice is to use denotational semantics for language standards.

X3J11 considered doing just that.  However, as you indicated, there
are disadvantages to such an approach, the main one probably being
that few of the intended target audience for the Standard would be
able to make heads or tails out of any of it.



More information about the Comp.std.c mailing list