C: The Complete Nonsense (4th Edition)

[Seebs]

Based on feedback from people here, I've concluded that it was possible
that the earlier edition of C: The Complete Nonsense did not provide the
reader with a fair, accurate, and reasonably comprehensive picture of
the quality of Herbert Schildt's book, "C: The Complete Reference".

Having put a few hours of work into reviewing the current edition, I have
created a new page which analyzes it in some detail. I have concluded that
the previous document significantly understated the abundance and depth of
misunderstandings and errors in Schildt's book. Even the 4th edition, in
which several errors pointed out in my previous page have been corrected,
continues to astound me with the sheer depth of its errors.

Perhaps more importantly, I had not previously noticed, or remarked on,
the great volume of things which were simply not covered by Schildt, which
should have been in any book purporting to teach C or to serve as a reference
for it. In fact, the errors of omission are in some cases more serious.

Anyway, here we have it:

http://www.seebs.net/c/c_tcn4e.html

Special thanks to a number of reviewers and commenters, especially Keith
Thompson and der Mouse, both of whom caught me out in a number of humorous
errors. (For what it's worth, I believe that one or two cases were ones where
I had mistakenly identified some of Schildt's writing as being in error, and
a dozen or more were cases where I had failed to spot all of the errors.)

As always, comments, corrections, and feedback are welcome. (Disclaimer:
By standing policy, I will delete any private contacts from Nilges unread.
I also won't actually read his posts, except for amusement value. If someone
thinks he's spotted a genuine error, feel free to bring it to my attention,
but I won't be holding my breath.)

-s

 

[Uno]

Based on feedback from people here, I've concluded that it was possible
that the earlier edition of C: The Complete Nonsense did not provide the
reader with a fair, accurate, and reasonably comprehensive picture of
the quality of Herbert Schildt's book, "C: The Complete Reference".

Having put a few hours of work into reviewing the current edition, I have
created a new page which analyzes it in some detail. I have concluded that
the previous document significantly understated the abundance and depth of
misunderstandings and errors in Schildt's book. Even the 4th edition, in
which several errors pointed out in my previous page have been corrected,
continues to astound me with the sheer depth of its errors.

Perhaps more importantly, I had not previously noticed, or remarked on,
the great volume of things which were simply not covered by Schildt, which
should have been in any book purporting to teach C or to serve as a reference
for it. In fact, the errors of omission are in some cases more serious.

Anyway, here we have it:

http://www.seebs.net/c/c_tcn4e.html

Special thanks to a number of reviewers and commenters, especially Keith
Thompson and der Mouse, both of whom caught me out in a number of humorous
errors. (For what it's worth, I believe that one or two cases were ones where
I had mistakenly identified some of Schildt's writing as being in error, and
a dozen or more were cases where I had failed to spot all of the errors.)

As always, comments, corrections, and feedback are welcome. (Disclaimer:
By standing policy, I will delete any private contacts from Nilges unread.
I also won't actually read his posts, except for amusement value. If someone
thinks he's spotted a genuine error, feel free to bring it to my attention,
but I won't be holding my breath.)

I guess I heard that from Heathfield years ago. Is anyone buying or
publishing this book still?

 

[James Harris]

       http://www.seebs.net/c/c_tcn4e.html ....
As always, comments, corrections, and feedback are welcome.

I can only really provide positive feedback. The examples are clear
and the page is very easy to read. I almost laughed out loud when I
read the acknowledgements.

A clickable table of contents would be helpful, something like

http://codewiki.wikispaces.com/bit_count_fast.c

I read your page as a block of text but some navigation aids or visual
clues to delimit sections and subsections would be useful for looking
back. The current header sizes are a clue but only a small one.

James

 

[Malcolm McLean]

Based on feedback from people here, I've concluded that it was possible
that the earlier edition of C: The Complete Nonsense did not provide the
reader with a fair, accurate, and reasonably comprehensive picture of
the quality of Herbert Schildt's book, "C: The Complete Reference".

You seem to have addressed most of my criticisms in the new version.
I'll have to actually get a copy of Schildt if I'm to comment much
more on this.

One new criticism I'd make is that the original was about the right
length for a review, this is over-long for that purpose. You might
like to think or rewriting the inital section so it can stand alone.

 

[Zarquon]

Seebs wrote:
[snip]

Having put a few hours of work into reviewing the current edition, I have
created a new page which analyzes it in some detail. I have concluded that
the previous document significantly understated the abundance and depth of
misunderstandings and errors in Schildt's book. Even the 4th edition, in
which several errors pointed out in my previous page have been corrected,
continues to astound me with the sheer depth of its errors.

Perhaps more importantly, I had not previously noticed, or remarked on,
the great volume of things which were simply not covered by Schildt, which
should have been in any book purporting to teach C or to serve as a reference
for it. In fact, the errors of omission are in some cases more serious.

Anyway, here we have it:

http://www.seebs.net/c/c_tcn4e.html

[snip]

Puzzlingly, this page appears to claim to be a year old, and this post
appears to claim that the page is new. What happened?

 

[Keith Thompson]

       http://www.seebs.net/c/c_tcn4e.html ...
As always, comments, corrections, and feedback are welcome.

[...]
A clickable table of contents would be helpful, something like

http://codewiki.wikispaces.com/bit_count_fast.c

I read your page as a block of text but some navigation aids or visual
clues to delimit sections and subsections would be useful for looking
back. The current header sizes are a clue but only a small one.

It does have a clickable table of contents; scroll down about a page
from the top to the "Contents:" section.

 

[Seebs]

You seem to have addressed most of my criticisms in the new version.
I'll have to actually get a copy of Schildt if I'm to comment much
more on this.

One new criticism I'd make is that the original was about the right
length for a review, this is over-long for that purpose. You might
like to think or rewriting the inital section so it can stand alone.

I don't really intend it as a review, so much as a meta-reference; something
people can go to when asking the question "why do people claim that Schildt
doesn't understand C". (Answer: Because he clearly could not figure out how
to address the order-of-evaluation, or EOF, criticisms.)

-s

 

[Seebs]

Puzzlingly, this page appears to claim to be a year old, and this post
appears to claim that the page is new. What happened?

.... I got the year wrong.

As I said, I absolutely DO NOT claim to not be prone to trivial and
obvious mistakes.

-s

 

[Seebs]

If you don't mind, I will review your review.

I am not sure that this document is a "review".

"The Structure of Scientific Revolutions, 3rd edition, Thomas S.
Kuhn, 1996, paperback, University of Chicago Press, ISBN
0-226-45088-3"

There are key pieces of information here, the book title, the
author, the edition, the date of publication, the publisher, and
the identifier. Carefully identifying the work you are reviewing
is rather like getting the prototype for main correct.

And if this were a "book review", I would definitely have done something
like that. I suppose I could do it anyway, but this is not a review.

The entire "objections" section could be profitably omitted. The
function of reviews is to critique the work being reviewed.
Polemics and self justifications are not to the point.

Again, this is not a review; it's a position paper on the question of whether
Schildt's writing is garbage.

Similarly
we do not need to know details of your personal life, e.g., that
you are autistic. Let your review stand on its own feet; do not
prop it up with crutches. Similarly the entire section "Herbert
Schildt and C: The Complete Nonsense" could profitably be
replaced by a single paragraph, a single sentence, or even
deleted entirely.

I disagree. Again, if this were a review, and a review of a single book,
that section would be irrelevant. But it's not. This is a discussion of
the question of whether C:TCR illustrates a complete failure on Schildt's
part to understand some basic components of C.

For that, it is important that the reader see that, confronted with reports
of blatant errors, Schildt could remove the offending material, but could
not correct it. Similarly, it's very instructive to note that, while Schildt
removed the offending sentence from the description of getchar(), he neither
removed the same sentence from the description of getc(), nor updated the
example to be correct.

What is wanted in this kind of review is an overview of the book,
its structure, its virtues such as they are, the kinds of errors
made, and its target audience.

I was unable to find any virtues, and the structure of the book was
uninteresting to me.

Are there entire topics where the treatment is fundamentally
mistaken, or are the errors mostly at a low level. This is an
important issue. Low level errors are readily corrected;
fundamental misunderstandings are more serious.

As pointed out, there does not seem to be a single reference, anywhere,
to structure padding.

From your text I
gather that most of the errors are:

(a) The use of DOS centric forms rather than the more general and
more portable forms specified by the standard.

These seem to be much reduced in the 4th edition.

(b) Simple slop - typos and other small errors that should have
been caught in editing.

It's hard to tell typos from misunderstandings. Is "=+" a typo, or
a conceptual error? I have no idea. His writing is not consistently
good enough for me to be sure he didn't intend it.

(c) Misuderstandings of basic utilities, e.g., feof.

That, I think, rises to the level of a "fundamental misunderstanding".
He doesn't show any comprehension of how conversions (such as character
to unsigned char to int) work.

(d) Code examples at does not work or even compile.

Most of them look like they'd compile now, most of the time.

(e) Code examples that have undefined behaviour.
Yes.

(f) Incorrect explanations of correct code.
Yes.

(g) Bad style. By this I mean the failure in code to check for
errors and handling them.

I'm fairly content to let someone skip error checking in a book,
at least some of the time. What bothers me is stuff like gets().

It would have been better if your review that there is little
discussion of subjects such as undefined behaviour and
implementation defined behaviour.

Ahh, but I haven't checked it out to see whether those topics might
be covered somewhere. I probably should at some point, but that wasn't
the primary topic of interest to me.

I just wanted to see whether the book was still littered with errors. It
is.

Similarly, is there any discussion of the variety of
implementation environments. At the time of the 4th edition
there were numerous unix and unix clone environments, DOS and NT,
DEC VMS and even a MVS implementation. Beyond that the hosted
implementations there are free standing environments. What about
this profusion of possible environments does the book say, if
anything?

Nothing significant that I spotted. This could arguably be justified
by claiming that, since the examples are portable, such details are
irrelevant.

-s

 

[James Harris]

       http://www.seebs.net/c/c_tcn4e.html ...
As always, comments, corrections, and feedback are welcome.

[...]
A clickable table of contents would be helpful, something like

 http://codewiki.wikispaces.com/bit_count_fast.c

I read your page as a block of text but some navigation aids or visual
clues to delimit sections and subsections would be useful for looking
back. The current header sizes are a clue but only a small one.

It does have a clickable table of contents; scroll down about a page
from the top to the "Contents:" section.

My bad. I was thinking about something more detailed - for example,
under the Pick-a-Page section clickable links to the page numbers; and
under the Higher-Level Problems heading a clickable entry for each
problem. My only complaint is that with no indentation the document is
a bit monolithic.

James

 

[Seebs]

My bad. I was thinking about something more detailed - for example,
under the Pick-a-Page section clickable links to the page numbers; and
under the Higher-Level Problems heading a clickable entry for each
problem. My only complaint is that with no indentation the document is
a bit monolithic.

This is not entirely a bad idea. I might do some indenting at some
point.

-s

 

[spinoza1111]

I am not sure that this document is a "review".


And if this were a "book review", I would definitely have done something
like that.  I suppose I could do it anyway, but this is not a review.

What is it? Oh, I know: a childish attempt to demonstrate that you
were a qualified programmer by damaging another man's reputation. You
did this instead of taking any computer science classes at university.

Again, this is not a review; it's a position paper on the question of whether
Schildt's writing is garbage.

Note how the pomposity of "position paper" clashes with the
prejudgement. News flash: "whether your writing (and the work of
McGraw Hill editors) is garbage" is biased from the start.

I disagree.  Again, if this were a review, and a review of a single book,
that section would be irrelevant.  But it's not.  This is a discussion of
the question of whether C:TCR illustrates a complete failure on Schildt's
part to understand some basic components of C.

You're not qualified and you have no standing:

(1) You have no Microsoft experience
(2) Schildt's got MSCS and BS in computer science. You have by your
own admission a BA in psychology and ADD.

This is borne out by the fact that your examples are jejune

For that, it is important that the reader see that, confronted with reports
of blatant errors, Schildt could remove the offending material, but could
not correct it.  Similarly, it's very instructive to note that, while Schildt
removed the offending sentence from the description of getchar(), he neither
removed the same sentence from the description of getc(), nor updated the
example to be correct.

You refused McGraw Hill's offer that you be a tech reviewer out of
laziness and greed. You have never done a thorough technical review,
therefore any one "error" that you have identified may not be an
"error".

I was unable to find any virtues, and the structure of the book was
uninteresting to me.

You're quite free with charges of "narcissistic personality disorder",
and I have complained to Paul Manning of Springer (your publisher)
about this in attempt to settle outside of a court of law, which is
where you're headed. However, you betray narcissism. If "the structure
of the book was uninteresting to you" and you have not thoroughly
reviewed any edition at any time, you had no business damaging
Schildt's reputation.

As pointed out, there does not seem to be a single reference, anywhere,
to structure padding.

This is probably because we don't choose as competent programmers to
write "vanity code" that is dependent on structure padding. You on the
other hand have a track record, in your queue.c fallthrough, of
writing vanity code.

These seem to be much reduced in the 4th edition.


It's hard to tell typos from misunderstandings.  Is "=+" a typo, or
a conceptual error?  I have no idea.  His writing is not consistently
good enough for me to be sure he didn't intend it.

I thought it was great! You say it is clear.
This is incomprehensible and this is queer.
You throw shit on the wall like an ape in the zoo
I suggest you desist before we all sue you.

That, I think, rises to the level of a "fundamental misunderstanding".
He doesn't show any comprehension of how conversions (such as character
to unsigned char to int) work.

To be precise, his understanding is not your business, since you don't
have the academic preparation to speak on this manner, nor the
practical programming experience: your current position seems to be
trivial bug finding by your own admission.

Most of them look like they'd compile now, most of the time.


I'm fairly content to let someone skip error checking in a book,
at least some of the time.  What bothers me is stuff like gets().


Ahh, but I haven't checked it out to see whether those topics might
be covered somewhere.  I probably should at some point, but that wasn't
the primary topic of interest to me.

So: you haven't read the books you have "reviewed"
Shame on you.

Tea Bagger moron.

I just wanted to see whether the book was still littered with errors.  It
is.

Godwin convergence time. You're nothing more than a cheap Nazi thug at
a book burning who hasn't read the books he burns but roots through
them like an ape for juicy bits.

 

[Seebs]

I vote for it being archaic code, and he may have intended it not
realizing it was archaic code, although I haven't seen the particular
spot in his books where he used that.

It's in an example somewhere, but I don't think "archaic" code is
plausible -- this book was started LONG after...

You are aware, aren't you, that the original C assignment operators
included =+, =-, =*, and =/, and *DID NOT* include +=, -=, *=, and
/= ?

Yes.

But that's a decade or two early to be the basis for something in a
book released in the mid to late 90s.

When did Schildt write the book containing that? Using =+ in a
book written about 1989-1990 when it was obsoleted in 1978 doesn't
say much for his book being up to date. But an old DOS C compiler
might have accepted it quietly if he compiled the code before
publishing it.

I am quite sure code was not in *general* compiled before publication,
because the 2nd edition used <> as an inequality operator, and there are
missing semicolons and the like in later editions.

-s