Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Using Macros
Message-ID: <17297@haddock.ima.isc.com>
Date: 8 Aug 90 22:55:06 GMT
References: <14339@shlump.nac.dec.com> <manning.650051935@gap> <151@smds.UUCP> <5439@stpstn.UUCP>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 23

In article <5439@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes:
>IMHO the many responders to this question gave the right answer to
>perhaps the wrong question.  The issues is not how to write the macro,
>but how to invoke it.  [Put braces around it.]

Your solution needs to be done at each invocation, whereas the other responses
fix the problem at the source.  In the best case (when the macro can be
written as an expression that evaluates each argument exactly once), the user
doesn't even need to know it's a macro.  This is a plus.

>Aside:
>	The one that really gets me is when someone does:
>	foo(gag) and you later discover that foo() is a macro.
>	Unfortunately, ANSI C has some of these.  Is there a
>	requirement that they are expressions?

With very few exceptions%, any functions that the vendor chooses to implement
as macros must have the property described above.

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
________
% assert() must under-evaluate when NDEBUG is set.  getc() and putc() may
  over-evaluate the stream argument.  I can't think of any others.