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