"Noalias" warning and questions

[Chris Calabrese[rs]]

In article <7256 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <10055 at ulysses.homer.nj.att.com> cjc at 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