C the complete nonsense

[Phil Carmody]

I've not yet had it happen.


In the 3rd edition, this covers "short __far _lineto(short x, short y);",
about which I can't tell you much, except that it ends with:

_lineto(600, 400);
getche();
_setvideomode(_DEFAULTMODE);

(we'll give him a pass on the "void main" since this is obviously
system-specific code.)

I'd have worded that "completely off topic for a C reference work, along
with the lines containing __far, _lineto, getche, and _setvideomode".

....

In the 4th edition, this is the page covering strtol and strtod.
We have:

This function reads base 10 numbers from standard input and
returns their long equivalent:

long int read_long(void)
{
char start[80], *end;
printf("Enter a number: ");
gets(start);
return strtol(start, &end, 10);
} ....
Also, it wouldn't hurt if the description of strtol were correct; while
this is, strictly speaking, on page 463, it's a great quote:

Finally, end is set to point to the remainder, if
any, of the original string. This means that if strtol()
is called with " 100 Pliers", the value 100L will be returned,
and end will point to the space that precedes "Pliers".

Very good, only it's not true. What's set to point to the remainder
of the original string is *the pointer pointed to by end, if end is
non-NULL*.

Given the context you've posted there, end is the pointer to char,
not to the pointer to pointer. But in that case, it's used in a
context where its address is taken, and therefore that address cannot
be NULL.

So it's certainly pretty garbled, and wrong one way or other.

Phil

 

[Keith Thompson]

In the 4th edition, this is the page covering strtol and strtod.
We have:

This function reads base 10 numbers from standard input and
returns their long equivalent:

long int read_long(void)
{
char start[80], *end;
printf("Enter a number: ");
gets(start);
return strtol(start, &end, 10);
} ...
Also, it wouldn't hurt if the description of strtol were correct; while
this is, strictly speaking, on page 463, it's a great quote:

Finally, end is set to point to the remainder, if
any, of the original string. This means that if strtol()
is called with " 100 Pliers", the value 100L will be returned,
and end will point to the space that precedes "Pliers".

Very good, only it's not true. What's set to point to the remainder
of the original string is *the pointer pointed to by end, if end is
non-NULL*.

Given the context you've posted there, end is the pointer to char,
not to the pointer to pointer. But in that case, it's used in a
context where its address is taken, and therefore that address cannot
be NULL.

So it's certainly pretty garbled, and wrong one way or other.

Right. The second parameter to strtol(), as documented in the
standard, is called "endptr", not "end":

long int strtol(
const char * restrict nptr,
char ** restrict endptr,
int base);

endptr is a char**; end is a char*.

You can't blame Schildt for the phrase "if end is non-NULL" being
garbled; Seebs said that.

Schildt's description appears to be correct. I'm even somewhat
impressed that he says that 100L, rather than 100, is returned.
But it's a description of *this call* to strol(), not of strtol()
in general. As commentary on the example, it's not bad, but
any description of strtol() should mention what happens when
endptr==NULL, and generally cover error handling; apparently Schild't
doesn't bother with any of that.

 

[Ian Collins]

Example

This function converts the number entered at the keyboard into its
absolute value:

#include "stdlib.h"

long int get_labs()
{
char num[80];

gets(num)

return labs(atol(num));

}

Actually, of course, it does no such thing, because it won't compile.

Of course it won't. There is a missing semicolon at the end of gets. A
professional programmer sees this and fixes it without making absurd
generalizations about the computer author. Whereas incompetents like
to play the back-stabbing game.

A professional programmer compiles and tests his code before submitting
it for review.

 

[Seebs]

In the 4th edition, this is the page covering strtol and strtod.
We have:

This function reads base 10 numbers from standard input and
returns their long equivalent:

long int read_long(void)
{
char start[80], *end;
printf("Enter a number: ");
gets(start);
return strtol(start, &end, 10);
} ...
Also, it wouldn't hurt if the description of strtol were correct; while
this is, strictly speaking, on page 463, it's a great quote:

Finally, end is set to point to the remainder, if
any, of the original string. This means that if strtol()
is called with " 100 Pliers", the value 100L will be returned,
and end will point to the space that precedes "Pliers".

Very good, only it's not true. What's set to point to the remainder
of the original string is *the pointer pointed to by end, if end is
non-NULL*.

Given the context you've posted there, end is the pointer to char,
not to the pointer to pointer. But in that case, it's used in a
context where its address is taken, and therefore that address cannot
be NULL.

So it's certainly pretty garbled, and wrong one way or other.

Oh, geeze, I didn't even catch that.

Schildt writes, on page 463:

#include <stdlib.h>
long int strtol(const char *start, char **end, int radix);

So what I said was right -- he should have said "the pointer pointed to
by end, if end is not NULL", but he also should have named it "endptr"
rather than "end", and/or used a different name in the example.

-s

 

[Seebs]

Schildt's description appears to be correct.

It's not, though, because the description is BEFORE the example,
and is referring to his (garbled) declaration.

The example code comes after the description, and reuses the name
"end" for a char *.

-s

 

[Keith Thompson]

It's not, though, because the description is BEFORE the example,
and is referring to his (garbled) declaration.

The example code comes after the description, and reuses the name
"end" for a char *.

I'm a bit confused. Does Schildt actually refer to the second
parameter to strtol() as "end" rather than as "endptr" (which is what
the standard calls it)?

Can you post some more context?

 

[Seebs]

I'm a bit confused. Does Schildt actually refer to the second
parameter to strtol() as "end" rather than as "endptr" (which is what
the standard calls it)?
Yes.

Can you post some more context?

strtol

#include <stdlib.h>
long int strtol(const char *start, char **end, int radix);

The strtol function converts... [brief description]

The strtol function works as follows. First, any white
space in the string pointed to by start is stripped[1].
Next, each character that makes up the number is read.
Any character that cannot be part of a long integer number
will cause this process to stop. This includes white space,
punctuation, and characters[2]. Finally, end is set to
point to the remainder, if any, of the original string.
This means that if strtol() is called with " 100 Pliers",
the value 100L will be returned, and end will point to the
space that precedes "Pliers".

[1] Yes, he says "stripped", not "skipped".
[2] I am pretty sure he meant "alphabetic characters which are not allowable
in the given radix", not just "characters". Also, obviously, "+" and "-" are
punctuation, but do not necessarily cause the process to end.

So, to answer the implicit questions:

1. Yes, he points out the "restrict" added by C99 in the material I didn't
reproduce.
2. Yes, he calls the parameter "end" rather than "endptr".
3. Yes, he is completely missing the distinction between "end" and
"the pointer pointed to by end".
4. Yes, I think that's because of his choice to rename the parameter.
5. The following example does indeed use a local variable "char *end"
and then pass &end to strtol.
6. So yes, the example "works" (nevermind the gets, etc., problems)...
7. But it's extremely confusing, and hopeless for a newbie trying to
follow along and wondering what "end" is and what it points to.

 

[Keith Thompson]

strtol

#include <stdlib.h>
long int strtol(const char *start, char **end, int radix);

[snip]

He didn't just rename endptr; he renamed *all* the parameters.

Their names in the standard are nptr, endptr, and base, respectively.

I suppose I can undererstand that "start" is clearer than "nptr", and
"radix" might be less ambiguous than "base".

But renaming "endptr" to "end" (and then passing "&end" as an
argument, so the caller's "end" is a char* and the callee's "end" is a
char**)? The only explanation I can think of is that he simplified it
to the point of incorrectness, without even realizing the distinction
between char* and char**.

In any case, especially in a reference, why not use the same parameter
names used by the standard?

 

[Seebs]

He didn't just rename endptr; he renamed *all* the parameters.
Yup.

But renaming "endptr" to "end" (and then passing "&end" as an
argument, so the caller's "end" is a char* and the callee's "end" is a
char**)? The only explanation I can think of is that he simplified it
to the point of incorrectness, without even realizing the distinction
between char* and char**.

In any case, especially in a reference, why not use the same parameter
names used by the standard?

No clue. Stranger yet, he DOES use it correctly -- it's just the
description that's totally wrong.

-s

 

[spinoza1111]

It's nice for Nilges to come out and say that his fundamental reason for
objecting to my page is that he wants to be able to commit a felony-level
unauthorized access to someone else's computers.  (Hint:  Once you're banned,
trying to sneak around the ban is, in fact, usually a felony, albeit not
one the cops are likely to pursue.)

This is simply not true. Wikipedia in fact has no legal claim that
"unauthorized" changes even exist since it is well known how to stop
them, but it wants them because that's how it steals intellectual
production. If I "hacked" into a closed site, that would be a felony.

But I would delighted to have you make the change to the Herb Schildt
article once you've seen the light.

Two of my "felonies" are now permanent content which have benefited
wikipedia. These were getting the entries on Herb and Kathy Sierra to
conform to wikipedia's own standard on Biographies of Living Persons
thereby protecting wikipedia against libel lawsuits.

Peter, if you weren't so evil, you'd be funny.

"Calling all cars...calling all cars. Felony in progress at Starbuck's
on Hysan and Perceval Road in Causeway Bay. Nilges is modifying
wikipedia."

Is Jimmy Wales making ignorant remarks on my blog a felony? Now
there's a guy I'd love to nail. He's probably committing tax fraud by
using wikipedia for his for-profit ventures. He's also a pompous,
ignorant shopclerk.

However, he's wrong; there are other pages that support the same point just
as well.

They are based on yours.

 

[spinoza1111]

[...]  The fact is, as he [Seebs] has himself confirmed, he
paid his way onto the ISO committee [...]

So did Schildt.  So what?

In fact, so did everyone I know of.  In fact, I'm the only person I know
to have been given a waiver of the fees (I was flat broke at the time) to
allow me to continue attending meetings and voting based on my contributions,
rather than based on sending in money.  (Only one year, but hey, it's a
data point.)

The difference is that Schildt paid the money for membership, then never
attended meetings or participated in any way that anyone I ever talked to is
aware of.

The issue isn't Schildt, it's you. He'd already published and finished
an advanced degree. Whereas I don't know what a person with no
academic preparation was doing at the C99 standard.
 

He paid money for the recognition and status.  Me, I went to

Maybe he heard you were there?

The issue is your behavior as regards CTCN, not Schildt.

 

[spinoza1111]

He didn't say that.


He didn't say that either.


He didn't say that either.


The problem here is not that you're bitter about the treatment you're
experiencing.  The problem is that most of the treatment you're experiencing
does not exist in the world external to you.  You are experiencing your
own bitterness, not the things people actually say to you.

On the contrary, there is objective evil in this newsgroup. You are
incapable of the simplest code, and you are using this ng in order to
pretend that you are qualified. Whereas Navia comes in here with lots
of working code and you enable attacks on him.

You make a ton of claims, such as that no one contributes or makes suggestions
about your projects, but people often do, and not all of them are "don't do
that".  I've given you several responses where I suggested improvements, or
agreed with one of your design criteria; in those cases, I've been arguing,
not that you shouldn't do a container library, but ways in which I think your
container library can be better.  I write those suggestions because it's
quite clear that you are passionate about this, and I am a big fan of trying
to help people do things that they think are important.

Since it's obvious that you could not write an equivalent piece of
software from queue.c, he probably has ignored your suggestions.

But it's pretty frustrating, because even though I've put a fair bit of time
into kibitzing, suggesting things, and trying to articulate things that I
think might be barriers to acceptance that you might need to overcome to get
widespread adoption... All you seem to hear is that I "don't like" it, so
you talk about people attacking you, trying to destroy you, and so on.

Which is what you're trying to do.

Serious question:  Do you know whether you might have some kind of serious
depression going on?  I have a few friends who are prone to depression, and
the kind of black fog of "everybody's hostile and just wants to destroy me"
stuff you say sounds a whole lot like what depressed people say.  If you
haven't looked into that before, I would suggest that you talk to a doctor
about it -- depression is dangerous, potentially lethal, and eminently
treatable.

I think the only depression he has is a strong desire to rearrange
your face.

 

[spinoza1111]

ImpalerCore a crit :







Yes, I should stop that container library.

I should stop giving my work for free, contribute to this group and
do my job where I get money for what I do.

You agree that calling me a jerk is good manners, but writing thomson
with lower case is an insult.

Nice for you, I did not expect anything else, from you or heathfield
and all the others.

Jacob, I suggest that you need to realize who your friends are here.
Stop defending yourself alone, like Bonaparte versus the English, the
Dutch and the Prussians at Waterloo. Take a look at how others are
being treated here by people who cannot get a one line strlen right.

I don't think Schildt's books are great. I do think that people have a
right to publish and be then free of criticism by their educational
and programming inferiors, criticism amplified by the hive mind of the
Internet. What's at stake here are the reputations of people who
actually do things, like you.

 

[Colonel Harlan Sanders]

Several bigshots, perhaps Wales, would like me to come back little
Sheba in order to get free content. Unfortunately I make my living at
teaching among other things philosophy, so why be a cow when the milk
is free (or something like that). Wales et al. want me to subject
myself to a Stalinist show trial in which I like Bukharin humbly admit
my failings. Which I sure won't.

You were banned precisely because you kept inserting your "content" in
Wikipedia. (And generally being an asshole, insulting other users, but
that's a given in any interaction with you.)
As in the case of the Schildt bio, you simply insist that your own
personal opinions are paramount. Wikipedia very specifically does not
want original content. It simply cites and summarizes existing
references. You can't just paste in long discursive essays based on
your own ideas.

If Peter simply blanks CTCN
I can go back and get the Reception section changed.

No you can't, because there are at least two other sources. And no,
they're not all clones of Seebach's article, as you keep stating,
falsely.

From the Wikipedia discussion page:

For the record: C programming professionals like Clive
Feather, Peter Seebach, and me do not rag on Herb
Schildt because we want to trash his reputation or
diminish his livelihood. We rag on his books because
they contain serious errors.
(With that said, I agree that any criticism section in
this Wikipedia article should be relatively small.
Anything on the scale of the excoriation this author
used to receive on comp.lang.c would certainly
be undue in its weight.) —Steve Summit

(And "relatively small" does not mean "none".)

Though really, why waste your time on this? I come across lots of
silly things in Wikipedia, sometimes I fix them, only to discover that
some obsessive has immediately reverted it and it's clear that a huge
effort would be needed to gather support to make a change stick. And
ultimately, Wikipedia is just a web page written by mostly anonymous
users. What you find there cannot be seen as either an endorsement or
an indictment. You're an idiot if you think that changing it either
way will change anyone's opinion of Schildt.

But you are an idiot. Even so, by now it must be obvious that
harassing, insulting and abusing Seebach has not intimidated him into
doing your bidding, Quite the reverse.

If you actually believe that Schildt has been unfairly described in
Wikipedia, instead of trying to censor opinions you disagree with, how
about you add some positive assessments, properly referenced. If
Schildt is as you say the paragon of C programming authors, then it
should be easy to find laudatory reviews from luminaries in the field.
(No, you can't cite yourself.)


A few references like "I only wish that I understood C half as well as
Herb Schildt -- Dennis Ritchie", "I must admit that Herb ghostwrote
most of the Art of Computer Programming -- Donald Knuth", and no one
would care what Seebach had written.

But that wouldn't give you an excuse to wage war on your enemies here,
and that's what you live for.

 

[spinoza1111]

I'm a bit confused.  Does Schildt actually refer to the second
parameter to strtol() as "end" rather than as "endptr" (which is what
the standard calls it)?
Yes.

Can you post some more context?

        strtol

        #include <stdlib.h>
        long int strtol(const char *start, char **end, int radix);

        The strtol function converts... [brief description]

        The strtol function works as follows.  First, any white
        space in the string pointed to by start is stripped[1].
        Next, each character that makes up the number is read.
        Any character that cannot be part of a long integer number
        will cause this process to stop.  This includes white space,
        punctuation, and characters[2].  Finally, end is set to
        point to the remainder, if any, of the original string.
        This means that if strtol() is called with " 100 Pliers",
        the value 100L will be returned, and end will point to the
        space that precedes "Pliers".

[1]  Yes, he says "stripped", not "skipped".

Stripped is sexier.

[2]  I am pretty sure he meant "alphabetic characters which are not allowable
in the given radix", not just "characters".  Also, obviously, "+" and "-" are
punctuation, but do not necessarily cause the process to end.

No, signs are not "punctuation".

So, to answer the implicit questions:

1.  Yes, he points out the "restrict" added by C99 in the material I didn't
reproduce.
2.  Yes, he calls the parameter "end" rather than "endptr".
3.  Yes, he is completely missing the distinction between "end" and
"the pointer pointed to by end".

It is common to collapse this distinction temporarily in teaching.

4.  Yes, I think that's because of his choice to rename the parameter.

You don't know what he knows.

5.  The following example does indeed use a local variable "char *end"
and then pass &end to strtol.

Translation: it is correct.

6.  So yes, the example "works" (nevermind the gets, etc., problems)...
7.  But it's extremely confusing, and hopeless for a newbie trying to
follow along and wondering what "end" is and what it points to.

Don't speak for the newbie. You're not a newbie. How would you know
what the knewbie kneeds to know?

But strangely, knor are you an experienced as opposed to corrupted
programmer. These sorts of corrupted and incompetent programmers love
to speak for the newbie.

English cannot be used as a formal metalanguage for C, therefore
anything that is said in English about C (such as what's set when end
is set) can be interpreted as wrong by hostile dweebs.

We now kneed you to blank or remove C: the Complete Nonsense. You
could do this silly set of silly operations on the example code of any
computer book, and we have learned that you produce code that is far
less competent. We're tired of you wasting bandwidth and patience.

 

[Colonel Harlan Sanders]

English cannot be used as a formal metalanguage for C, therefore
anything that is said in English about C (such as what's set when end
is set) can be interpreted as wrong by hostile dweebs.

And can be used by kooks to interpret it as correct:

You fail to notice that Schildt is using "long integer" in its
contemporaneous sense

We now kneed you to blank or remove C: the Complete Nonsense. You
could do this silly set of silly operations on the example code of any
computer book, and we have learned that you produce code that is far
less competent. We're tired of you wasting bandwidth and patience.

"We"?

And "wasting bandwidth": Until you started this a few months ago,
Seebach had NEVER MENTIONED SCHILDT here for at least 7 years that I
can see. And he has only responded to a small proportion of your
provocations.

Anyway, we're all waiting for you to "take this to the next level".
(Well, here "we" could just mean me, I must admit.)

What would that be? A Gandhi-style "fast unto death" unless the page
is removed? A PETA-style naked picketing of Seebs' workplace? Mailing
packets of brown powder to Jimmy Wales with "The next one will be
anthrax unless you withdraw the Schildt page."? Or just blurting out
hundreds of posts here of psychotic rants?
My bet is on the latter.

 

[Seebs]

And can be used by kooks to interpret it as correct:

Hee.

"We"?

"kneed"?

Anyway, the fact is, no, I couldn't do that to most books -- especially
not good ones. Believe me, I *tried* to find problems in King's
"C Programming: A Modern Approach". I found a handful. They were
nearly always pure typos or things where, while what he said was correct,
I thought it could be clarified.

And "wasting bandwidth": Until you started this a few months ago,
Seebach had NEVER MENTIONED SCHILDT here for at least 7 years that I
can see. And he has only responded to a small proportion of your
provocations.
Uh-huh.

What would that be? A Gandhi-style "fast unto death" unless the page
is removed? A PETA-style naked picketing of Seebs' workplace? Mailing
packets of brown powder to Jimmy Wales with "The next one will be
anthrax unless you withdraw the Schildt page."? Or just blurting out
hundreds of posts here of psychotic rants?
My bet is on the latter.

Well, let's see.

I assume Nilges would be happy if I were to alter the page to clearly
indicate that:

* It described a previous edition.
* Some of the issues described had been corrected in future editions.
* The page was no longer current.

Right? (Because, hey, guess what... That might be about to happen.)

Hey, cool thing. C:TCR 3rd edition contains the egregious error of
claiming that you must use feof() to determine whether end of file
has occurred on a binary stream, "because EOF is a valid integer
value".

It claims this on getchar(), which is covered in C:TCN. In the 4th
edition, that language is removed from the getchar() example.

It also claims this on getc(), which is NOT mentioned in C:TCN. And
in the 4th edition... That language is still there.

Conclusion: It is no coincidence that things mentioned in C:TCN have
been fixed in the 4th edition. And the fact that some of them were
fixed *incorrectly* suggests to me that, quite possibly, Schildt really
simply *did not understand* the relevant material. The reason that
the horrible order-of-evaluation example was replaced, not with a
corrected example, but with a much simpler example, is perhaps that
Schildt couldn't make sense of the rules.

He removed the "obviously wrong" text from getchar() -- where I'd pointed
it out -- but not from getc(). In both cases, the examples of usage he
gives still use 'char ch' to store the results of getchar() or getc().
Which is to say... He didn't *understand* the criticism, so he just
reacted to the specific claim I called out, and didn't actually fix the
GLARINGLY OBVIOUS flaws in his sample programs.

Similarly, he fixed the error (page 247 in the 3rd edition) of using
fseek on a text-mode file.

Which is to say:

1. Schildt acknowledges, implicitly, that C:TCN is authoritative and
correct -- that is to say, the things where I was pointing out a
language feature, not just criticizing the readability of the writing,
have been corrected in the 4th edition.
2. Specifically, Schildt makes it clear that it is C:TCN itself, not
some other source, that he's working from, by editing EXACTLY the things
criticized, while leaving identical errors in place and failing to
address closely related flaws in example programs in the very next
paragraph.
3. Schildt still doesn't understand (or didn't when the 4th edition
came out) how getchar() works, or how you can tell when input has started
failing without using feof() or ferror().
4. In short, Nilges is completely wrong. The corrections in C:TCN are
recognized as authoritative and correct, and as denoting actual flaws
in C:TCR, by the author or technical editor.
5. In short, Nilges is completely wrong. Schildt does not understand
the material in the book well enough to comprehend the criticisms, which
is why his "fixes" are all at the brute-force level without any
resolution of the deeper issues with the poor writing or explanations.

Now that I've got such excellent evidence that, in fact, Schildt did
indeed correct things specifically because of C:TCN, I think we're done
here -- we've established with reasonable confidence that everyone,
including Schildt, grants the correctness of the criticisms in question.

-s

 

[Nick Keighley]

I'd like to play too! Is shildt's book online somewhere?

long int get_labs()
{
    char num[80];
    gets(num)

isn't using gets() a bug all on its own?


it's supposed to be a book for beginners. An error rate of one per
page is way too high. The schildt was proposed as a error rate
measure- though milli-schildt would be better for professional
programmers.

The space shuttle software is expected to achive nano-shildt levels of
relibility.

A professional programmer compiles and tests his code before submitting
it for review.

I understand the publishing process can introduce bugs. Didn't
Unleashed have some bugs entered between submission by the authors and
actually being marks on dead trees?

 

[Nick Keighley]

(3) As Malcolm has pointed out, code snippets are not standalone and
not meant for [...] programmers to type in
uncritically. [...]

a fair point (once edited), I suppose

(4) It is in fact common practice to eliminate housekeeping and to
make assumptions when one's a teacher, but neither you nor Richard are
teachers. [...]

nor is schildt
you simply have to have a better grasp of your subject than schildt
has to qualify as a teacher

(Sigh) without looking at your garbage below, we know that Herb, while
he correctly parenthesizes the formal parameters in the macro, failed
to take into consideration what will happen when the macro is used in
a larger expression with an operator of lower precedence than ?:.

this is prettyy basic stuff. If he's writing a book about C he should
know this.

Many beginners fail to parenthesize formal parameters and are
surprised when shit happens as a result. They then are admonished to
use parentheses.

but schildt isn't a beginner, he's a teacher of beginners

Given your low standard of care in using a switch statement with
fallthrough,

was it wrong? I use the feature when its useful, though I usually
comment it heavily. Where multiple labels have the same action its
quite common

switch (event)
{
case EV_DATA:
process_data();
break;

case EV_ACK:
case EV_CONT:
special_processing();
break;

case EV_BREAK:
break_link();
break:

default:
bad_event();
}

I rather doubt in fact that you know or follow either
standard consistently, and given, Peter, your [sloppiness in usenet post]

[...]

shildt is supposed to be writing a book not a usenet post

<snip>

 

[spinoza1111]

"kneed"?

Anyway, the fact is, no, I couldn't do that to most books -- especially
not good ones.  Believe me, I *tried* to find problems in King's
"C Programming: A Modern Approach".  I found a handful.  They were
nearly always pure typos or things where, while what he said was correct,
I thought it could be clarified.


Well, let's see.

I assume Nilges would be happy if I were to alter the page to clearly
indicate that:

* It described a previous edition.
* Some of the issues described had been corrected in future editions.
* The page was no longer current.

I might be, especially if you review the wording with me by email
before making any change and also propose how you shall correct the
Reception section of the wikipedia article. If we can come to an
agreement, and you perform your part, I will undertake to never again
post on this issue, unless you make a new commentary on the fourth
edition. If you do so, I shall review it for a thoroughness, lack of
own error, and proper use of English, and post my comments here. I
think it would be best if you stopped wasting your time on Schildt
commentary, however.

Yes, we have freedom of speech. Let us use it more constructively. I
would really rather be coding software and teaching.

Right?  (Because, hey, guess what... That might be about to happen.)

Hey, cool thing.  C:TCR 3rd edition contains the egregious error of
claiming that you must use feof() to determine whether end of file
has occurred on a binary stream, "because EOF is a valid integer
value".

It claims this on getchar(), which is covered in C:TCN.  In the 4th
edition, that language is removed from the getchar() example.

It also claims this on getc(), which is NOT mentioned in C:TCN.  And
in the 4th edition... That language is still there.

Conclusion:  It is no coincidence that things mentioned in C:TCN have
been fixed in the 4th edition.  And the fact that some of them were
fixed *incorrectly* suggests to me that, quite possibly, Schildt really
simply *did not understand* the relevant material.  The reason that
the horrible order-of-evaluation example was replaced, not with a

We've been over this, Peter. The only way in general to avoid a
"horrible order of evaluation error" in using macros is to do two
things:

1. Parenthesize all formal parameters

2. Surround macros meant to generate one or more C statements with
curley brackets; surround macros meant to generate expressions with
round parentheses

For good measure, as a belt and suspenders, the USER can also add
these characters at the point of call, and let the compiler do a very
small amount of extra work.

Although I do this consistently, this and other standards I use make
my code strange to mortal men, and because most programmers code
macros strictly for their own use, this standard is seldom followed by
programmers in practice. The "horrible" error was yours in that you
showed code in which the precedence is unexpected, so it wasn't, in
terms of praxis, an error on Herb's part at all.

It is indeed time for you to climb down and post language in CTCN as
you say you might.

corrected example, but with a much simpler example, is perhaps that
Schildt couldn't make sense of the rules.

Do him the courtesy of not further speculating on his competence. Just
point out errors and be cool in the future.

He removed the "obviously wrong" text from getchar() -- where I'd pointed
it out -- but not from getc().  In both cases, the examples of usage he
gives still use 'char ch' to store the results of getchar() or getc().
Which is to say... He didn't *understand* the criticism, so he just
reacted to the specific claim I called out, and didn't actually fix the
GLARINGLY OBVIOUS flaws in his sample programs.

Similarly, he fixed the error (page 247 in the 3rd edition) of using
fseek on a text-mode file.

Which is to say:

1.  Schildt acknowledges, implicitly, that C:TCN is authoritative and

Give me a break on this.

correct -- that is to say, the things where I was pointing out a
language feature, not just criticizing the readability of the writing,
have been corrected in the 4th edition.

I rather doubt this.

2.  Specifically, Schildt makes it clear that it is C:TCN itself, not
some other source, that he's working from, by editing EXACTLY the things
criticized, while leaving identical errors in place and failing to
address closely related flaws in example programs in the very next
paragraph.

Did he credit you? "Finally, I would like to acknowledge the
invaluable contributions of Peter Seebach, a valued mentor, friend,
gentleman and scholar". Does anything like this appear in the 4th
edition? I rather doubt it.

3.  Schildt still doesn't understand (or didn't when the 4th edition
came out) how getchar() works, or how you can tell when input has started
failing without using feof() or ferror().
4.  In short, Nilges is completely wrong.  The corrections in C:TCN are
recognized as authoritative and correct, and as denoting actual flaws
in C:TCR, by the author or technical editor.
R.O.T.F.F.L.M.F.A.O

5.  In short, Nilges is completely wrong.  Schildt does not understand
the material in the book well enough to comprehend the criticisms, which
is why his "fixes" are all at the brute-force level without any
resolution of the deeper issues with the poor writing or explanations.

Now that I've got such excellent evidence that, in fact, Schildt did
indeed correct things specifically because of C:TCN, I think we're done
here -- we've established with reasonable confidence that everyone,
including Schildt, grants the correctness of the criticisms in question.

Not quite. Please send me the wording you plan to put at the page, and
plan to put it at the top of the page. Please also inform me of the
changes you propose to make to the wikipedia entry.