Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!pasteur!ucbvax!ulysses!cjc From: cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) Newsgroups: comp.lang.c Subject: Re: "Noalias" warning and questions Message-ID: <10074@ulysses.homer.nj.att.com> Date: 15 Feb 88 15:54:56 GMT References: <8012@elsie.UUCP> <10055@ulysses.homer.nj.att.com> <7256@brl-smoke.ARPA> Organization: AT&T Bell Laboratories, Murray Hill Lines: 56 Summary: standardization won't eliminate #define's In article <7256@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <10055@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: > >... I put all kinds of #define and #if and #ifdef > > To the extent that standardization can eliminate some of that, > it would be highly desirable. I agree, but for systems work this is self contradictory. > C is used for much more today than originally intended. I would > bet that most C programming is targeted for non-UNIX systems now. > Certainly there is very little in the language proper that could > be construed as designed for UNIX, although the standard C library > is slanted slightly toward UNIX. There are many who think that > even for systems use on UNIX, having a C standard would be of value. Of course all the non-Unix systems which C is popular on have file systems (and even process scheduling, in some cases) which are similar, if not derived from, Unix. Look at MS-Dos for example. The MS-Dos file system is a complete rip-off of Unix. Unix was a virtural revolution in the operating systems world, and most of the Unixy things in C have been adopted by all the major operating systems around. Remember, at the time Unix was designed (late 1960's), you couldn't do character oriented i/o in a portable manner, except in Lisp. I realize that C is used for many things other than what it was originally intended for, in fact I do very little 'systems' programming; however, that doesn't mean the language should be changed to be useless for its original purpose just to accomodate these new uses. > It isn't the committee that is responsible for C being applied to > other situations than the one you think it should be used for. > Besides, the issue of optimization (which is what started this > discussion) is mostly application-independent. I still say that if a program is really going to take up enough system time to need really good system dependant optimization, the programmer is responsible for it, and there is no really portable way that the language design can solve these problems, given the restraint of a non functional (i.e. language is designed to execute a execute a series of steps in order, not solve problems in a more abstract manner) model on the language. Of course this gets us into the area of programms which are created by program generators, but that's another can of worms. But what do I know, I haven't even been accepted to graduate school yet. Christopher Calabrese AT&T Bell Labs ulysses!cjc