mjs@hubcap.clemson.edu (M. J. Saltzman) (04/24/91)
In article <72969@brunix.UUCP> gvr@cs.brown.edu (George V. Reilly) writes: >In article <680@taumet.com> steve@taumet.com (Stephen Clamage) writes: >+ The ANSI C standard says explicitly that a union may contain a bitfield. > >Well, that's another thing that Harbison & Steele III have got wrong, >then. On p. 128, it says: > The syntax for defining components [in unions] is the same > as that used for structures, except that bit fields are > not permitted in unions. 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? E-mail is fine, I don't want to take up more bandwidth than I already have. Thanks very much. Matthew Saltzman mjs@clemson.edu
vinoski@apollo.HP.COM (Stephen Vinoski) (04/26/91)
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 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. -steve | Steve Vinoski (508)256-0176 x5904 | Internet: vinoski@apollo.hp.com | | HP Apollo Division, Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | | "The price of knowledge is learning how little of it you yourself harbor." | | - Tom Christiansen |
mjs@hubcap.clemson.edu (M. J. Saltzman) (04/27/91)
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? Thanks. > > >-steve > > >| Steve Vinoski (508)256-0176 x5904 | Internet: vinoski@apollo.hp.com | >| HP Apollo Division, Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | >| "The price of knowledge is learning how little of it you yourself harbor." | >| - Tom Christiansen | Matthew Saltzman mjs@clemson.edu
gvr@cs.brown.edu (George V. Reilly) (04/27/91)
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