Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: ANSI proposal for preprocessor strings
Message-ID: <5194@utzoo.UUCP>
Date: Sat, 9-Mar-85 19:25:37 EST
Article-I.D.: utzoo.5194
Posted: Sat Mar  9 19:25:37 1985
Date-Received: Sat, 9-Mar-85 19:25:37 EST
References: <9058@brl-tgr.ARPA>
Organization: U of Toronto Zoology
Lines: 32

> >The ANSI C standard wants to support TOKENIZED preprocessing.
> >The character-string based kludges possible with the Reiser CPP
> >do not fit into this concept.
> 
> I don't see what the problem is.  You have to deal with strings
> specially anyway to handle \n, et. al., right?  So, at the same time,
> divide it up into tokens and see if any match the macro parameters.
> Note that you only have to do this if the string is in a parametered
> macro definition, so the overhead shouldn't be too bad.  

The trouble is that these two operations (escape processing and macro
handling) often take place at quite different times.  I know of at
least one compiler (admittedly, an obscure one) which doesn't really
deal with string escapes until code-generation time.  Others deal with
them right away, as the string is being scanned, well before anyone
knows that it's part of a macro.

Nobody's claiming that the Reiser things are impossible, just that they
are awkward to do, unclean in concept, undocumented, and not widely
accepted in non-Unix implementations.

> Anyway, its not clear that the standard should not include something
> only because it might be hard to implement in a certain manner.


Why not?  That's the way C has developed so far.  Why change a winning way?

To my mind, the "undocumented", "unclean in concept", and "not widely
accepted in non-Unix implementations" parts are rather more significant.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry