Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Why I won't use ANSI C Message-ID: <7170@brl-smoke.ARPA> Date: 24 Jan 88 22:16:32 GMT References: <7563@elsie.UUCP> <7022@brl-smoke.ARPA> <7564@elsie.UUCP> <7053@brl-smoke.ARPA> <5212@utah-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 87 In article <5212@utah-cs.UUCP> donn@utah-cs.UUCP (Donn Seeley) writes: >'The committee couldn't care less whether existing implementations can >run correctly written ANSI C programs.' I'm not aware of ANY programming language standard (except possibly for Minimal BASIC, which nobody uses) that had as a goal what Donn apparently wants for the C standard. The lowest-common-denominator intersection across all C implementations is just too small to waste time on, since nobody would want to use such a puny subset. If you don't believe this, then you must not have encountered a significant fraction of the many existing C implementations. > And another goal is to remedy clear deficiencies. > <7053@brl-smoke.ARPA> >'The committee feels free to ignore existing practice if it will help >solve political problems.' It takes quite a leap of logic to conclude that these are equivalent! X3J11 has by no means been "ignoring existing practice"; to the contrary, a continual goal has been to ensure that Standard C implementations will be able to support existing correctly-written C source code. >I feel that it was and is possible to have a standard that would >maximize interchange of software between existing C implementations ... That is NOT the goal of the C standard nor of any other major language standard. Existing implementations simply differ too much to make this a better alternative than arranging for FUTURE enhanced portability across much richer and more useful C environments. We cannot, of course, guarantee portability of existing applications among existing implementations, since whether or not they are portable is already determined and is not changed by adopting any sort of a "standard". >As a programmer, I can't imagine why a standard that doesn't do this would be useful to me. I suggest that you attempt this feat, and see what you end up with. Be sure to include IBM 370, Honeywell, H-P 3000, MS-DOS, Macintosh, etc. in your list of pre-existing implementations to be included in your "standard". At best, you'll end up with some "portability guidelines for C programming", such as you can find in several textbooks. Such "portability" is either too weak to be useful, or else it requires defining a lot of implementation-dependent parameters in header files, providing a lot of OS interface routines, etc. The implementor ends up doing about as much work to provide such a "portable" environment as with the more usual approach taken by X3J11. The programmer generally ends up with MORE work with such an approach, since the less that things are specified, the more that (portable) code has to be written in terms of parameters. I fail to see what service that would be to the C community! >I will be writing my own programs in (say) C++, a language which really is >advancing the art, and which has yet to be 'improved' by committee... Just wait until the C++ variants start multiplying. Then those trying to write portable "production" applications will clamor for standards for C++! It is true that you don't need programming language standards much if you're doing CS research rather than production programming, or if you don't have to support more than a few types of system. It is also premature for C++ to standardize much, since it is still undergoing change. It's the major reason that I will still be using C rather than C++ in the near future for applications that we fully expect to be in heavy use 20 years hence. Since you've been so obnoxious about this, I'll report that we had one hell of a time trying to import code written at your institution, due to its being terribly dependent on features present in a particular C compiler you used but not promised by K&R and in fact not present in at least one of our local compilers. (In fact, the need to avoid such hassle was one of three major determinants for the type of computer and OS we subsequently bought. We opted to get one just like yours! Clearly this situation is to be avoided if possible.) Note that much of this non-portable C usage was for the express purpose of getting around deficiencies in the K&R-specified language, things that the new C Standard will be requiring portable support for in future C compilers. Seems to me X3J11 is doing the job right, plus or minus epsilon.