Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Macro parameters getting substituted into strings
Message-ID: <7566@brl-smoke.ARPA>
Date: 27 Mar 88 16:15:03 GMT
References: <11879@brl-adm.ARPA> <4099@hoptoad.uucp> <7309@brl-smoke.ARPA> <983@mcgill-vision.UUCP> <4253@hoptoad.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <4253@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>In the BSD sources, Keith Bostic and I had to change more than 50 files
>to deal with this.

Don't say that Berkeley wasn't informed of this nonportable usage
many years ago, before X3J11 in fact.  I recall that several of us
pointed it out, to no avail.  (In my System V emulation, when I
needed macros like Berkeley's _IOR, I defined mine the right way.)

>Can you say "Codifying existing practice", boyz and goils?

Can you say, "codifying existing correct practice"?

Macro substitution inside string literals and character constants was
explicitly disallowed by K&R, and many independent implementations of
C followed the rule.  For such implementations, requiring the Reiser
cpp behavior would have been a change to existing practice with
visible adverse effects on existing correct code, and there is more
support for their point of view than for that of Reiser cpp abusers.

>My preferred way to fix this would be for ANSI C to allow the *
>(indirection) and [] (subscripting) operators on string literals in
>constant expressions.

I could support this, or some char-ize operator, but I don't think
they'll make it into the standard at this point.  Char-ize had been
proposed before in several forms; I forget whether subscripted
string literals in constant expressions had ever been proposed.

Send it in.