Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.lang.c
Subject: Re: Re: ANSI proposal for preprocessor strings
Message-ID: <3827@mit-eddie.UUCP>
Date: Mon, 18-Mar-85 23:43:03 EST
Article-I.D.: mit-eddi.3827
Posted: Mon Mar 18 23:43:03 1985
Date-Received: Wed, 20-Mar-85 04:05:40 EST
References: <8436@brl-tgr.ARPA> <454@ucsfcgl.UUCP> <5152@utzoo.UUCP> <1369@utah-gr.UUCP> <5195@utzoo.UUCP> <1380@utah-gr.UUCP>
Reply-To: barmar@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, Cambridge, MA
Lines: 21

In article <1380@utah-gr.UUCP> donn@utah-gr.UUCP (Donn Seeley) writes:
>We may not personally like or use Reiser preprocessor extensions, but
>what right have we to break programs that use them?  (Maybe I should
>rephrase that -- why should we who have never used or needed features
>like token replacement in strings dictate to those who do?)

On the other hand, what right do we have to break programs that AREN'T
expecting these incompatibilities.  The big problem with this
controversial issue is that there is no way to standardize it such that
it is compatible for everyone.  Several posters have already included
simple examples that do not use the in-string replacement feature and
will break if compiled with this feature.  I think it goes something
like
	#define MACRO(d) printf("%d", d)
I think that the standard committee made the right choice in their
compromise; it provides the facility, but in an upward-compatible
fashion.
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar