Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!ringworld.Eng.Sun.COM!eager
From: eager@ringworld.Eng.Sun.COM (Michael J. Eager)
Newsgroups: comp.lang.c
Subject: Re: H&S (WAS: meaning of continue)
Message-ID: <2032@exodus.Eng.Sun.COM>
Date: 3 Nov 90 05:46:09 GMT
References: <27261@mimsy.umd.edu> <16103:Oct3003:39:4890@kramden.acf.nyu.edu> <493@taumet.com> <27203:Oct3103:49:2290@kramden.acf.nyu.edu>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 34

In article <27203:Oct3103:49:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>You don't understand. I don't *want* to have to wade through all that
>stuff about newer C. The language described by the original K&R isn't
>defined precisely---but it's the language I use, and the language that
>compilers understand. And that's exactly what I want.
>

>
>Your code is likely to be even more portable if you use K&R as your
>reference. That's all I'm saying.
>

I have to throw my 2 cents in. 

Here's the hypothetical question:  If K&R was so clear and wonderful
why did H&S write their book and why did the ANSI committee form to 
standardize the language?  The answer is that K&R is not clear, it
doesn't match the implementations, and doesn't completely describe
the language as used or implemented. 

Part of the impetus to standardize C was problems writing portable
code.  For example, different integer promotions.  Or the different
collection of library routines supplied with different compilers.  Or 
the different operation of identically named functions.  Or the various
interpretations of multiple external variable definitions.  

Porting C code which is ANSI conformant is easier than code which
works on some version of C, but only on that version.  And, naturally,
that version is not available, so you have no idea what the program
was supposed to do when it doesn't work correctly.  

There you have it.  Flame off.

-- Mike Eager