Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!utah-cs!utah-gr!donn From: donn@utah-gr.UUCP (Donn Seeley) Newsgroups: net.lang.c Subject: Re: Re: ANSI proposal for preprocessor strings Message-ID: <1369@utah-gr.UUCP> Date: Wed, 6-Mar-85 19:27:10 EST Article-I.D.: utah-gr.1369 Posted: Wed Mar 6 19:27:10 1985 Date-Received: Fri, 8-Mar-85 03:45:59 EST References: <8436@brl-tgr.ARPA> <454@ucsfcgl.UUCP> <5152@utzoo.UUCP> Organization: University of Utah CS Dept Lines: 36 Henry, I fear your argument by analogy is weak. Did it ever occur to you that implementations of Berkeley Unix exist on many computers other than the VAX? (Sun, NBI, NSC, Tektronix, Pyramid, Convex, ...) The Reiser preprocessor undoubtedly followed most if not all of these ports with little alteration; the inline assembler code did not. (If inline assembler is protected by preprocessor conditional compilation directives, as it really should be, porting is no problem either, although the generic code will often run slower than customized assembler code. Register assignment conventions such as the ones Henry discusses have not perceptibly impeded the porting of Berkeley Unix, although I agree they are probably unnecessary.) The C preprocessor supplied with System V is also Reiser-based and appears to contain the same extensions (our sole System V machine is dead with disk problems but a quick study of the sources supports my conclusion). The Reiser preprocessor is part of a portable software environment that is used in many places; in fact it would not surprise me to hear that the vast majority of C programmers use the Reiser preprocessor, although I have no statistics on this. The Reiser preprocessor's string substitution behavior is clearly one of the most popular C extensions, and for that reason alone deserves careful consideration. I find it more than a little odd that it is given such short shrift by some participants in this discussion when rather more radical proposals such as case ranges are being casually bandied about. My own feeling is that the ANSI C standard is not the place to make C perfect; C (including its common extensions) has enough imperfections that it seems pointless to break existing code just to fix a tiny fraction of them. I suggest that people concentrate their corrective impulses on a new language, such as C++. Try to guess how I feel about Fortran 77, Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn