Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!eos!aurora!labrea!decwrl!pyramid!prls!philabs!micomvax!zap!iros1!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: macros with parameters in MSC 5.0
Message-ID: <983@mcgill-vision.UUCP>
Date: 10 Mar 88 07:17:41 GMT
References: <11879@brl-adm.ARPA> <4099@hoptoad.uucp> <7309@brl-smoke.ARPA>
Organization: McGill University, Montreal
Lines: 51

In article <7309@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <4099@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>> jbaker@ee.UCLA.EDU (Joe Baker) wrote:
>>> #define ctl(c) ('c'&037)
>> This change caused us to have to fix more than 50 files in Berkeley
>> Unix.  [...A useful capability was removed, and replaced with a less
>> capable set of features.]
> First, this was NOT a change to the C language.  K&R already
> guaranteed that macro substitution would not occur inside string and
> character literals (section 12.1 of Appendix A).

So?  Macro arguments aren't macros.  I looked for a statement in K&R
that said that Reiser behavior was forbidden and failed to find
anything clear-cut.

The statement in 12.1 of Appendix A says that "Text inside a string or
a character constant is not subject to replacement.", but they don't
make it clear whether they mean replacement of macros with their
expansions or all replacement arising from the preprocessor.

> I daresay there are more instances of C compilers currently that do
> not do such substitution than those that do; [most that do are
> derived from AT&T's Reiser cpp].

Are you sure?  I would have guessed the other way.  I have no idea
where to look to obtain statistics to settle this; can anyone cite any
reference to such numbers?

> To see what is wrong with the Reiser method, try [...]:
> #define TEST(a,b) ((void)fprintf(stderr,"This is a test: 0x%x\n",(a)^(b)))

Yeah, and to see what's wrong with the ++ operator, try:

main() {  int i,j;
          i = 7;
          j = i++ + i++ + i++;
          printf("i = %d, j = %d\n",i,j);  }

The behavior exhibited by Reiser preprocessors is "wrong" only in that
it isn't how you believe it ought to work.  I see nothing wrong with
it.  The cited piece of K&R arguably supports you, but it arguably does
not support you.  And I claim that history supports me, because the
Reiser cpp is closer to the original cpp, the one used back when K&R
was written, than anything else around.  (Or at least so I believe, but
on trying I find I can't provide a source for this claim.  Can anyone
cite a source to support or demolish it?)

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu