Why I won't use ANSI C

[Doug Gwyn]

In article <5212 at utah-cs.UUCP> donn at 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 at 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.