Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!brunix!gvr
From: gvr@cs.brown.edu (George V. Reilly)
Newsgroups: comp.std.c
Subject: Re: Harbison & Steele (was: Re: Bitfields in unions)
Message-ID: <73708@brunix.UUCP>
Date: 27 Apr 91 07:59:07 GMT
References: <72969@brunix.UUCP> <1991Apr23.212105.28138@hubcap.clemson.edu>
	    <5134adce.20b6d@apollo.HP.COM>
	    <1991Apr26.191616.22666@hubcap.clemson.edu>
Sender: news@brunix.UUCP
Reply-To: gvr@cs.brown.edu (George V. Reilly)
Organization: Dept. of Computer Science, Brown University, Providence RI
Lines: 109

In article <1991Apr26.191616.22666@hubcap.clemson.edu>, mjs@hubcap.clemson.edu
(M. J. Saltzman) writes:
# In article <5134adce.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM 
# (Stephen Vinoski) writes:
# > In article <1991Apr23.212105.28138@hubcap.clemson.edu>
# > mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
# > + Sorry to bother you all, but does anyone have a list of errata for
# > + H&S?  Is it really that bad?  Are there any other good references
# > + (short of the standard itself) for day-to-day use?

# > Several weeks ago I posted a problem with the strcat() function shown
# > in the book.  Sam Harbison contacted me and seemed to indicate that he
# > was putting together an errata list to be mailed out.

# > My original posting seems to have started a thread which has
# > inadvertantly given the book a bad reputation.  

# I actually didn't see this thread.  My posting was in response to
# another thread about whether unions could contain bit fields.  The
# tone of the post (which I don't have anymore) seemed to be: "Damn!
# *Another* error in H&SIII!"  I was concerned, because I found the 
# earlier editions to be very useful, and when H&SIII came out, I
# went right out and bought it.  It surprised me that there might be
# more significant problems with the new edition.

# > I have been reading H&S III *very* closely ever since.  Most of the
# > problems I have encountered in the book so far are typographical,
# > e.g. misspellings, font changes, missing tabs.  The "real" problems
# > like those that have pointed out in this newgroup are few and far
# > between.

# > A C reference manual is bound to be very complex; given that fact, I
# > would have to say that the error density of H&S III is very, very
# > low.  In my opinion, the book is definitely good enough for
# > day-to-day use, and I highly recommend it.

# I'm glad to hear it.  It certainly wasn't my intention to contribute
# to the negativity.  Since I've only started following this group 
# recently, could someone send me a list of what's been found so far?

Matthew is referring to my remark about H&S being wrong about whether
bitfields are permitted in unions or not.  It wasn't quite as negative
as he remembers; more resigned than infuriated.

In article <72969@brunix.UUCP>, gvr@cs.brown.edu (George V. Reilly) wrote:
| Well, that's another thing that Harbison & Steele III have got wrong,
| then.  [They said bitfields are forbidden in unions, the Standard
| explicity permits them.]

Let me first say that I like H&S3, despite its flaws and errors.  It's
still a good book, but not as good as it could have been.  It's a
clear, readable book which presents a lot of material in a
well-organized manner.  Visually it's a lot more attractive than H&S2
which was really rather ugly.  I particularly liked the way they
contrasted the ANSI and traditional libraries side-by-side in Part 2.

However, the standard of proofreading for H&S3 was appallingly low.
There are literally hundreds of minor but obvious spelling and font
mistakes that should have been caught by even non-technical
proofreaders.  That they weren't causes one to lose confidence in the
technical accuracy of the book.

If the book had been a rush job to describe the new ANSI standard, the
number of errors would be more understandable, if no more forgiveable.
(That was H&S2 :->)  But the Standard was published over a year before
H&S3 and had been in its final form for about a year before that.

I haven't gone through the book with a fine toothcomb, but a casual
perusal dipping into the book at random yielded several errors and a
list of things that I would have done differently.  None of the
following are fatal flaws, but neither should they have slipped through.

p. 110: `p<array[N]' should read `p<&array[N]'.
p. 128: the already discussed union bitfield mistake.
p. 185: `the strrev function below copies into its first argument a
	 reversed copy of its second argument.'  Swap `first'
	 and `second'.  (Also wrong in H&S1 and H&S2.)
p. 226: in insertsort(), temp is used but not declared.  (It was
	correctly declared in H&S1 and H&S2, interestingly.)
p. 233: `The idea is to find the largest element in the array'.
	Make that `smallest element'.  (Also wrong in H&S1 and H&S2.)
p. 287: the strcat() bug of a few weeks ago.

Some things that I Would Have Done Differently:

Nowhere (that I could find---the index isn't all that it might be
either) do they explicitly state that one should always cast NULL to a
pointer of the appropriate type when passing a null pointer to an
unprototyped or variadic function.

In the `tricky but fast' identity matrix initialization on p. 173,
they count UP:
	for (i = 0; i < SIZE*SIZE; i++) {...}
It would have been trickier and probably faster to have counted down:
	for (i = SIZE*SIZE; --i >= 0; ) {...}

The pow() example on pp. 221 and 225 uses (exponent % 2) and
(exponent /= 2) to get the lowest bit of exponent and shift exponent
right by one bit respectively.  I don't know why they didn't write
(exponent & 1) and (exponent >>= 1) instead.

The bibliography is out of date: it should mention K&R2 and the second
edition of Sedgewick's _Algorithms_ or better yet _Algorithms_in_C_.

They've dropped some material which I liked, such as the long example
on sets.
________________
George V. Reilly   `Waiting for H&S4'	gvr@cs.brown.edu   +1 (401) 863-7684
uunet!brunix!gvr   gvr@browncs.bitnet	Box 1910, Brown U, Prov, RI 02912