Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.lang.c
Subject: Re: #define CTRL(x) followup
Message-ID: <560@mcgill-vision.UUCP>
Date: Sat, 22-Nov-86 19:08:38 EST
Article-I.D.: mcgill-v.560
Posted: Sat Nov 22 19:08:38 1986
Date-Received: Mon, 24-Nov-86 19:29:29 EST
References: <7136@elsie.UUCP> <779@valid.UUCP> <5396@brl-smoke.ARPA>
Organization: McGill University, Montreal
Lines: 47

In article <5396@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <779@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes:
>> Guess I came into the discussion late.  What's wrong with the Reiser
>> treatment (it's always worked for me)?
> Unfortunately the Reiser CPP didn't follow the rules in K&R, whereas
> many other C compilers did.  No matter what was chosen for this
> issue, some "working code" was going to break.

I thought we'd been over this already.  K&R is not totally clear on
this point.  The index refers to two places for "preprocessor".  One of
them (page 86) states that
	Substitutions do not take place within quoted strings, so, for
	example, if YES is a defined name, there would be no
	substitution in printf("YES").
while the other (page 207) states that
	Text inside a string or character constant is not subject to
	replacement.

Neither one clearly forbids the Reiser cpp's interpretation, which
appears to be that formal parameters are expanded to their actuals
inside strings (and character constants) in the macro definition, but
that macros expansion itself *is* suppressed by such quotes.

The first quote does not address the issue; the second is open to
interpretation of "replacement" - is it just macro expansion (Reiser)
or also formal parameter substitution (the others)?

This is completely separate from the token concatenation issue, which
is another Reiser stumbling block.

Personally, I like the Reiser way of doing things in the first case; in
the second, I don't care (the ANSI way (## isn't it?) is just as good
as /**/ for gluing two tokens together).

Does ANSI C permit the analogue of the following?
	#define foobar baz
	#define x(y) foo/**/y
	x(bar) /* expands to baz */

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu

[USA NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode]