ANSI proposal for preprocessor strings

Donn Seeley donn at utah-gr.UUCP
Fri Mar 15 19:29:04 AEST 1985


Re Henry Spencer's latest comments...

Henry, I'm afraid your response misses my point somewhat.  Programs
that use Reiser preprocessor features will run under most major species
of Unix; programs that use inline assembler are lucky to run anywhere.
As for documentation, postings in this group this week have
demonstrated that the string substitution feature was documented at
AT&T/Bell.  And of course there are legions of programmers who learned
C by imitation and picked up features not in K&R that were used by more
sophisticated (less scrupulous?) programmers.  To insist that
programmers, and more importantly, programs, somehow forget this is
fighting the tide.

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 used to
be arrogant too (and still am if I can get away with it) -- if I saw
code that wasn't written adhering to my high standards of style, onto
the heap it went.  Perhaps it's my old age, but I've mellowed
considerably and no longer look forward to months of beating someone
else's code into shape and getting it to work right again once I've
torn it apart and rebuilt it.

My experience with attempting to maintain part of the Unix Fortran
compiler has led me to take the position that, as well-intentioned and
as thorough as the ANSI Fortran committee was, Fortran 77 is a
disaster.  The standard broke and continues to break programs.  Writing
a program that will run under all of the various existing compilers is
a nightmare, because the committee failed to include some of the most
common extensions to the language.  The only program I have ever seen
that even attempts to be truly portable is the XTAL suite from the
University of Maryland, and I have great admiration for the
implementors and I'm very happy that I didn't have to do what they did
(which is write everything in RATFOR, supplying a complete RATFOR
compiler with every distribution, and parameterizing absolutely
everything with macros).  Just this last week I got mail from someone
who wants to be able to assign character strings to non-character
variables.  This extension is present in most Fortrans but is ruled out
by the standard.  This person has a huge set of utilities which would
be extremely difficult to modify to suit full Fortran 77, and if I
don't make the change, either (a) someone else will do it or (b) they
will simply forget about porting their utility to Unix.  What right
have I to refuse?

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?)

I'm afraid Henry has misread my comments about the discussion of the
preprocessor -- I was referring to the net when I said that some
participants were not treating the issue seriously, not to the
committee.  I did read Larry Rosler's comments on the committee
proceedings and I thought they were very interesting.  I'm very worried
that the C standard is going to turn into something bizarre, despite
Larry's best efforts.  We have already heard Dennis Ritchie's comments
on the issue of strong typing in C and (I may be mistaken, I don't have
a copy of the current draft) it appears that they are being ignored.
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?

As long as we're considering case ranges, how about COMMON statments,

Donn Seeley    University of Utah CS Dept    donn at utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn

PS -- I used to have Alan Watt's wonderful 'TTI C formatting standard'
article pinned to my wall, but the ink faded out.  Guess I'll have to
print another copy...  Maybe I'll have it framed this time.



More information about the Comp.lang.c mailing list