ANSI proposal for preprocessor strings
Henry Spencer
henry at utzoo.UUCP
Fri Mar 22 03:37:54 AEST 1985
I'll try to be brief, I'm really sick of this issue...
> ... Programs
> that use Reiser preprocessor features will run under most major species
> of Unix...
Of course, this has little to do (nowadays) with what fraction of C
compilers they will run under. This is net.lang.c, not net.unix,
remember?
> As for documentation, postings in this group this week have
> demonstrated that the string substitution feature was documented at
> AT&T/Bell.
But nowhere else. This is net.lang.c, not net.unix or att.lang.c...
> I'm not particularly persuaded by your claims of innocence with regard
> to the string substitution feature. I have never used the feature
> either, but it's not my code I'm worried about, it's the other guy's.
> Pureness of heart will not save you from having to maintain 10
> megabytes of source for some utility which YOU DIDN'T WRITE!
I would sympathize with this more if the problem were hard. It's not;
detection of Reiserisms, and conversion to the ANSI-draft primitives,
can be purely mechanical. This is not like (say) multiple external
definitions, where there is no simple mechanical way to convert.
> 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?)
Speaking as someone who intends to implement this swill in a compiler,
I think I do have a right to object to it.
> The C preprocessor extensions strike me as being just as ugly and bogus
> as the Reiser extensions, with the quibble that the Reiser extensions
> at least appear in a set of widely used C implementations. What in the
> world are we going to end up with?
I agree about ugliness and bogusness, and my #1 preference would be to
see token concatenation and stringizing eliminated completely, as a
regrettable aberration of one particular implementation. Alas, it is
not to be... At least the argument is merely over how to do something
that's already (ugh) accepted as part of C; this isn't quite the same
as gratuitous addition of new goodies, however well-intended.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
More information about the Comp.lang.c
mailing list