Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

C: The Complete Nonsense (4th Edition)

12 views
Skip to first unread message

Seebs

unread,
Apr 9, 2010, 12:15:42 AM4/9/10
to
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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Uno

unread,
Apr 9, 2010, 5:09:38 AM4/9/10
to

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

James Harris

unread,
Apr 9, 2010, 9:22:03 AM4/9/10
to
On 9 Apr, 01:15, Seebs <usenet-nos...@seebs.net> wrote:
...
>        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

unread,
Apr 9, 2010, 9:46:24 AM4/9/10
to
On 9 Apr, 01:15, Seebs <usenet-nos...@seebs.net> wrote:
> 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

unread,
Apr 9, 2010, 3:10:04 PM4/9/10
to
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?

--
Thinkers travel in cognito.

Keith Thompson

unread,
Apr 9, 2010, 3:40:41 PM4/9/10
to
James Harris <james.h...@googlemail.com> writes:
> On 9 Apr, 01:15, Seebs <usenet-nos...@seebs.net> wrote:
> ...
>>        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.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Seebs

unread,
Apr 9, 2010, 5:17:04 PM4/9/10
to

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.)

Seebs

unread,
Apr 9, 2010, 5:17:57 PM4/9/10
to
On 2010-04-09, Zarquon <eter...@pobox.com.invalid> wrote:
> 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. :)

Richard Harter

unread,
Apr 9, 2010, 5:33:32 PM4/9/10
to
On 09 Apr 2010 00:15:42 GMT, Seebs <usenet...@seebs.net>
wrote:

>Anyway, here we have it:
>
> http://www.seebs.net/c/c_tcn4e.html


If you don't mind, I will review your review. As a preliminary
remark it is quite clear that the book in question is error
ridden and filled with bad code and bad advice. Your conclusions
are not in question, except perhaps by fulminators offering
shabby excuses for the inexcusable whilst they conduct obscure
personal vendettas.

That said, your essay has faults. As a beginning, the beginning
lacks an important piece of information - a precise
identification of the work you are reviewing. Here is an example
from one of my reviews:

"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.

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. 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.

Now to more serious matters.

Too much of the text of your review is concerned with minor
quibbles at the lowest of levels. It quickly becomes tedious and
leaves the impression that you only see the smallest of issues.

That said, your review does make it clear that the book is error
ridden, that it is sloppy, and it contains misunderstandings of
the C language. This is enough to warn off anyone considering
buying it. However its day is long gone, so warnings are not to
the point.

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.

It would have been better (though more tedious for you) if you
had gone through the entire book rather than picking pages and
sections at random. If you had you would have better been in a
position to answer such questions as:

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. 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.

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

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

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

(e) Code examples that have undefined behaviour.

(f) Incorrect explanations of correct code.

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

This modest list suggests that there are some very serious things
missing from the book. C is a notoriously dangerous language; it
is all too easy to write plausible looking code that compiles and
runs, but none-the-less contains booby traps. From what you have
quoted, it appears that Schildt had no real understanding of how
easy it is to fall into the booby traps nor how to avoid them.
It would have been better if your review that there is little
discussion of subjects such as undefined behaviour and
implementation defined behaviour.

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?

And so on and so forth.



Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

Seebs

unread,
Apr 9, 2010, 6:06:35 PM4/9/10
to
On 2010-04-09, Richard Harter <c...@tiac.net> wrote:
> 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.

James Harris

unread,
Apr 9, 2010, 8:28:51 PM4/9/10
to
On 9 Apr, 16:40, Keith Thompson <ks...@mib.org> wrote:

> James Harris <james.harri...@googlemail.com> writes:
> > On 9 Apr, 01:15, Seebs <usenet-nos...@seebs.net> wrote:
> > ...
> >>        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

unread,
Apr 9, 2010, 8:49:46 PM4/9/10
to
On 2010-04-09, James Harris <james.h...@googlemail.com> wrote:
> 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.

Gordon Burditt

unread,
May 27, 2010, 3:21:00 AM5/27/10
to
>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 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.

You are aware, aren't you, that the original C assignment operators
included =+, =-, =*, and =/, and *DID NOT* include +=, -=, *=, and
/= ? They were present in that old form in the UNIX v6 C compiler
(about 1975), and were obsoleted in K&R I (1978) and the UNIX v7
compiler (1979) used the new assignment operators. Some compilers
continued to support that form in addition to the new ones for some
time after that. One particularly ugly form was x=-1;, which was
ambiguous as to whether it meant x=(-1); vs. x=-(1); (and I forget
which one it was supposed to mean).

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.

spinoza1111

unread,
May 27, 2010, 4:28:26 AM5/27/10
to
On Apr 10, 2:06 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-04-09, Richard Harter <c...@tiac.net> wrote:
>
> > 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.

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.


>
> > 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.
>

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.

> > 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.

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".


>
> > 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.

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.


>
> > 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.

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.


>
> > 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.
>

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.

> > (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.

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.


>
> > (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.

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.

>
> > 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
> --

> Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

unread,
May 27, 2010, 5:27:05 AM5/27/10
to
On 2010-05-27, Gordon Burditt <gordon...@burditt.org> wrote:
>>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 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.

0 new messages