ANSI, K&R, H&S (was: Re: Just a minor new twist on free())

[Stephen E. Witham]

In article <PDS.90Oct10093245 at lemming.webo.dg.com>, pds at lemming.webo.dg.com (Paul D. Smith) writes:
> [People] said things like:
> 
>     In general the ANSI features added are not hard to avoid using,
>     except for things like enums and <<add a list of your own
>     favourite "add on" C features>> ... so go ahead and use the common
>     (but non-K&R I) features, but avoid the uncommon ones; they're not
>     portable.
> 
> This seems to me to be inherently unportable...  

I agree.  "Common, non-K&R features" are illusions and traps!

> IMHO, if you're going to go whole-hog with interoperability, then you
> have to have a definition of what you are interoperable with...
> 
> The only definition I know of is K&R I, which, while I agree it's a
> great book, just does not do the job as far as nitty-gritty
> specifications of the entire language.  

Yes, mostly, to all of that.  It's either ANSI C or Least Common Denominator
(LCD) C.  But even K&R is not a reference to LCD C, for two reasons:
   1) K&R is unclear at times.
   2) Even when K&R is clear, implementations get it wrong.

The closest thing to a reference to LCD C is _C: A Reference Manual_, by
Harbison and Steele.  The whole point of the project that led to the book
was to seek out the fuzzy edge of C, see what was really happening there,
and FIGURE OUT HOW TO AVOID IT.  The book is full of advice like, "Don't
use this feature," or, "Sometimes this doesn't work, sometimes this doesn't 
work, so the most conservative and portable way to do it seems to be this..."

Stephen Clamage tried to make this same point to Dan Bernstein, but slipped
up by talking about "portable" and "enums" in the same sentence.  That was a
real disservice to Mr. Bernstein's understanding the value of H&S, viz:
> 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.

I can't speak for how hard it is for Mr. Bernstein to flip past the few
sections that describe features not in K&R.  But H&S DOES describe K&R C--
CLEARLY.  

Earlier, Mr. Bernstein had said:
> ...K&R (the real one) can be used as a
> reference. If you recognize its ambiguities as true ambiguities, you'll
> write much more portable code.
Then, later,
> Maybe I would agree with Chris that H&S is the best reference if I ever
> needed more precise interpretations than there are in K&R. But I don't.

If you have an intuitive understanding of where the ambiguities are, and
somehow just know that you will never find yourself in a grey area, then by 
all means stick with K&R.  If, you want to be explicitly warned about the 
ambiguities in K&R, and about where some implementations don't live up to 
K&R, and given good advice about what to do about it, then get H&S.

Mr. Bernstein says:
> Your code is likely to be even more portable if you use K&R as your
> reference. That's all I'm saying.
and IMHO that's exactly wrong.

The final reference for portability, of course, is experience.  Don't use
features that have bitten you in the past on any machine.  That's why I'm
surprised by Paul Smith's comment:
> In addition, I don't think
> I've seen a C program in the last 8 years which does not use any
> language features except those found in K&R I!

What kind of insulated environments do these people work in, anyway?

Steve Witham, The Squeaky Wheel 
(who doesn't know his own net address)
VoiceNet: (617)625-2856

"The Tao that can be dialed is not a working Tao."