C the complete nonsense

[Malcolm McLean]

I've been asked by Edward Nilges to comment on this webpage.
I had kept out of it, partly because of the tone of the debate, partly
because, not having read "C the complete reference" I don't have a
qualified opinion on the book.
The webpage is too focused on errors to be considered a review, and it
is too partisan to be considered an errata document. Much mention has
been made on comp.lang.c of legal liability. I've no idea what the
legal situation would be, except that this sort of "knocking copy" is
very commonly available on the web.

I think the title of Schildt's book invites misplaced criticism.
Whilst the book is entitled a "reference" it is in fact a tutorial.
The needs of pedagogy and definition are often opposed. A beginner
needs an explanation in simple, everyday language. A reference work
requires definitions, free from all error. It's very easy to find
errata in books full of teaching code, particularly if you adopt
stringent criteria. One reason is that the code is written for
demonstrating purposes,a nd never tested in a real environment. The
errors are obviously undesireable, but seldom have much impact on the
book's effectiveness for its purpose.

The very first error in "C the complete nonsense" is:

In general, negative numbers are represented using the two's
complement approach...
This is not a C feature. It is a common implementation, but it is
specifically not required. (Binary is, but one's complement is not
unheard of.)

This is suprious, Schildt qualifes by "in general".

The next one is
The following heading occurs:

static Global Variables
No such thing. A static variable outside of a function has file scope,
which is distinct from global scope.

Whilst I haven't read the book, this is probably spurious as well. The
term "global variable" can be used either for file scope variables or
variables with external linkage.


Enough said. Two errors in two errata. I could go on, doing exactly
the same thing to "C the complete nonsense" as Seebs has done to
Schildt.


I don't like libel laws and I think threats of legal action are heavy-
handed, and not credible unless they come from the person allegedly
libelled himself. I suspect Schildt himself just regards this sort of
criticism as the inevitable concomitant of success. The books do very
well on the market, and no-one is forced to buy them. However Nilges
is actually right, "C the complete nonsense" is a bad webpage and
should be either removed or substantially revised.

 

[Keith Thompson]

I've been asked by Edward Nilges to comment on this webpage.

And you decided to do so? Ok, whatever.

I had kept out of it, partly because of the tone of the debate, partly
because, not having read "C the complete reference" I don't have a
qualified opinion on the book.
The webpage is too focused on errors to be considered a review, and it
is too partisan to be considered an errata document. Much mention has
been made on comp.lang.c of legal liability. I've no idea what the
legal situation would be, except that this sort of "knocking copy" is
very commonly available on the web.

I think the title of Schildt's book invites misplaced criticism.
Whilst the book is entitled a "reference" it is in fact a tutorial.

What is misplaced about criticizing a misleading title?

The needs of pedagogy and definition are often opposed. A beginner
needs an explanation in simple, everyday language.

A beginner also needs an explanation that's *correct*. Many of
Schildt's errors are just errors; there would be no pedagogical harm
in correcting them.

[...]

The very first error in "C the complete nonsense" is:

In general, negative numbers are represented using the two's
complement approach...
This is not a C feature. It is a common implementation, but it is
specifically not required. (Binary is, but one's complement is not
unheard of.)

This is suprious, Schildt qualifes by "in general".

The phrase "in general" is ambiguous; it can mean either "usually" or
"always". Assuming that "in general" was meant as "usually", he could
(and IMHO should) have mentioned that other representations exist.

The next one is
The following heading occurs:

static Global Variables
No such thing. A static variable outside of a function has file scope,
which is distinct from global scope.

Whilst I haven't read the book, this is probably spurious as well. The
term "global variable" can be used either for file scope variables or
variables with external linkage.

And is therefore ambiguous, and therefore IMHO should be avoided in a
book that purports to teach C.

Enough said. Two errors in two errata. I could go on, doing exactly
the same thing to "C the complete nonsense" as Seebs has done to
Schildt.

So why did you stop after just two errors? If it was inappropriate
for Seebs to list just a subset of the errors rather than covering the
entire book, is it fair (to your readers, if not to Seebs, Schildt,
or Nilges) to criticize C:TCN based on just the first two errors?

In a quick reading, it appears to me that the first two listed errors
happen to be the least substantial. Keep reading. The third error
is a use of "%f" to print an expression of type size_t (followed by
a use of "%d" for the same purpose, but that's not *quite* as bad
an error). The fourth is an application of sizeof to a parameter
of type int[6], which is really of type int*. These are just plain
wrong, and they're demonstrations that Schildt didn't even try his
code before publishing it. The printf format error *might* be a
typo, perhaps one introduced in typesetting, but the sizeof error
is just a fundamental conceptual misunderstanding on Schildt's part.

And he claims to be teaching C.

As long as I'm posting I'll mention that
The "heap" is a DOS term...
is a perfectly correct statement. It doesn't necessarily imply
that it's *only* a DOS term. It also happens to be a Unix term,
and a Windows term, and a Symbian term, and so forth (and yes,
an updated version of the web page should probably clarify that).
The point is that it isn't a C term.

(Nilges doesn't seem to understand -- or maybe he does -- that the
more he keeps pushing his agenda, the more attention will be brought
to Schildt's errors.)

I don't like libel laws and I think threats of legal action are heavy-
handed, and not credible unless they come from the person allegedly
libelled himself. I suspect Schildt himself just regards this sort of
criticism as the inevitable concomitant of success. The books do very
well on the market, and no-one is forced to buy them. However Nilges
is actually right, "C the complete nonsense" is a bad webpage and
should be either removed or substantially revised.

I disagree completely. "C: The Complete Nonsense" is a valuable
warning to those who might otherwise be misled by reading Schildt's
books. It could stand some revision, particularly an update to the
latest edition of the book.

 

[Seebs]

I think the title of Schildt's book invites misplaced criticism.
Whilst the book is entitled a "reference" it is in fact a tutorial.

I disagree. It *contains* a tutorial, but it also *contains* a reference.
The book has whole chapters of material which is structured and presented
as a reference.

It is a reference. It is sold as a reference, it claims to be a reference,
and it contains material structured like a reference. That it also contains
a tutorial doesn't change that.

It seems to me that maybe you ought to look at the book at least a little
before claiming that it's actually "a tutorial".

Furthermore, the fact is, when these books were selling well and people using
them came to this group, we consistently found that the book was a VERY BAD
tutorial -- people who learned C from Schildt had a horrible time learning
the language, because he does a very good job of creating cognitive maps
which are wrong, whether subtly or obviously.

This is suprious, Schildt qualifes by "in general".

I don't think that qualification is strong enough to cover for the fact
that making this claim doesn't help at all with the teaching.

Whilst I haven't read the book, this is probably spurious as well. The
term "global variable" can be used either for file scope variables or
variables with external linkage.

Not correctly.

Enough said. Two errors in two errata. I could go on, doing exactly
the same thing to "C the complete nonsense" as Seebs has done to
Schildt.

You probably could -- but I think that you'd find that, even once you
nitpicked the nitpicks, you'd find that the substantive errors MASSIVELY
outweighed them.

Why did you pick two of the worst errata, rather than looking at, say,
the example where Schildt totally misidentifies the behavior of sizeof(),
or shows the use of %f to print a size_t?

I don't like libel laws and I think threats of legal action are heavy-
handed, and not credible unless they come from the person allegedly
libelled himself. I suspect Schildt himself just regards this sort of
criticism as the inevitable concomitant of success. The books do very
well on the market, and no-one is forced to buy them. However Nilges
is actually right, "C the complete nonsense" is a bad webpage and
should be either removed or substantially revised.

Obviously, I don't agree. I agree that it might be beneficial to revise
the page... But why bother? The book in question is fifteen years old,
and modern editions, while they continue to teach extremely bad habits,
are still full of nonsense.

I am pretty offended that you seem to have gone out of your way to
cherry-pick bad examples rather than reading the whole selection and
developing an informed opinion. All you're doing here is supporting
a pathological and unrepentant abuser who has stated that his goal
in participating here is to attack the C language, C users, and this
newsgroup.

I do not think the material in C:TCN is particularly bad. Some of it's
not particularly good, but there's plenty there to demonstrate that
many of the errors in the book are absolutely beyond the scope of what
could reasonably come from someone even reasonably familiar with C.

-s

 

[Seebs]

So what you're actually saying is that the first error is on the front
cover.

Basically. I would really like to know where this notion that it was
not a "reference" came from. Is this more Nilges stuff? His never-ending
list of mutually-exclusive claims as to why the book should not be
panned is too large for me to remember.

But really, I've read it, I've seen people use it. It's sold as a
reference, it's structured to be used as a reference, the book explicitly
states that it is intended for use by experienced programmers who need
to keep a reference around for looking things up...

The notion that it's "not a reference" is incomprehensible. It's a BAD
reference, to be sure, but that doesn't mean it's not a reference.

Where did that notion come from?

-s

 

[Bill Reid]

I've been asked by Edward Nilges to comment on this webpage.
I had kept out of it, partly because of the tone of the debate, partly
because, not having read "C the complete reference" I don't have a
qualified opinion on the book.

And yet, like all members in good standing in this group,
here you are posting about it...

The webpage is too focused on errors to be considered a review, and it
is too partisan to be considered an errata document.

It might be good dessert topping...

Much mention has
been made on comp.lang.c of legal liability. I've no idea what the
legal situation would be, except that this sort of "knocking copy" is
very commonly available on the web.

I heard on TV that there's a bunch of crap on the
web but maybe they're just jealous...

I think the title of Schildt's book invites misplaced criticism.
Whilst the book is entitled a "reference" it is in fact a tutorial.
The needs of pedagogy and definition are often opposed.

You know, you think and sound a little like "SpinNosey"
hisself...

A beginner
needs an explanation in simple, everyday language.

Well, this is an important point, but you're missing it,
again as a member in good standing in this group.

When you write a book (or a newspaper/magazine article,
or even a short story/novel, for that matter), you must
always consider two things: your target audience, and
where you want to take them.

Now when you say "beginner", what do you mean in the
context of the target audience for the book? "SpinNosey"
seems to think that the target audience are people who
have college degrees in Computer Science or an equivalent
knowledge level. This is fine, but does the book
really address THAT audience correctly in terms of
"taking them" to an understanding of "C" given their
CS knowledge?

A reference work
requires definitions, free from all error. It's very easy to find
errata in books full of teaching code, particularly if you adopt
stringent criteria.

I'm going to cut you off here, because you're talking
crap...you'd thank me if you knew how stupid you sound
in the next few sentences, so I'll snip them as a favor
to your family...

The very first error in "C the complete nonsense" is:

In general, negative numbers are represented using the two's
complement approach...
This is not a C feature. It is a common implementation, but it is
specifically not required. (Binary is, but one's complement is not
unheard of.)

This is suprious, Schildt qualifes by "in general".

OK, but let's get back to my question: what PRACTICAL
lesson has a person with CS knowledge learned about "C"
from the above?

I'm actually thinking they may have a LITTLE something
out of it, so I kind of agree with you it may be "spurious"
to call that an "error"...but then I definitely DON'T
have a CS degree, you'd have to tell me what the point
is of the above...

The next one is
The following heading occurs:

static Global Variables
No such thing. A static variable outside of a function has file scope,
which is distinct from global scope.

Whilst I haven't read the book, this is probably spurious as well. The
term "global variable" can be used either for file scope variables or
variables with external linkage.

OK, here we go, read carefully. Once again, I'm no
CS guru, but IN GENERAL I think those people are
concerned about SCOPE and DURATION of variables in
a program.

Now here is a defining moment to impart an important
lesson to the CS audience about "C", and to me it seems
he blows it.

As you may or may not know, "C" uses the "static"
keyword differently in different places, and I think
very counter-intuitively and confusingly for ANYBODY,
BUT PARTICULARLY I WOULD THINK FOR A CS PERSON.

I mean what's your first thought when you hear
the word "static" in a computer programming context?
I know what MINE is, but how about you? Not that it
matters, since you're gonna be confused by the "static"
keyword no matter what. "C" is a very democratic language,
it screws over EVERYBODY who comes in contact with it.

In fact, it's basically a "feature" of the language
to do things sideways, bass-ackwards, upside-down,
and as inconsistently as possible. It's almost like
a practical joke played on the world by socially
maladjusted dorks taking out their revenge for
a tragic series of high school humiliations.

Now what I just wrote is, I believe, the only
CORRECT way to teach ANYBODY the "C" programming
language. If you include this in the Forward
to the book, it alerts the reader that they will
be encountering numerous examples of confusing
non-logic as they "learn" about "C".

Then when you come to the "static" keyword,
they're prepared to be flummoxed by "C" using
the word to RESTRICT scope in some places
and EXPANDING duration in others...and they're
much more likely to learn AND REMEMBER the
"rules".

But every book about "C" I've ever read was
a COMPLETE WASTE OF TIME, even if it was "accurate",
because it failed to EXPLAIN the language, but
rather gave an implied EXCUSE by merely reciting
the "facts". Then when somebody actually tries
to write a "C" program and fails, they think
it's THEIR fault, and not the fault of the
language creators and book authors...BUT THE
TRUTH IS, FAILURE TO WRITE A "C" PROGRAM JUST
MEANS YOU'RE AN INTELLIGENT, CARING, DECENT,
NORMAL HUMAN BEING!!!

And as far as the subject book is concerned,
a header of "static Global Variables" DEFINITELY
counts as an error in MY book, per the above...

Enough said. Two errors in two errata. I could go on,

No you couldn't, because when people say, "I could
go on", THEY NEVER CAN, they're just quitting while
they're ahead...

doing exactly
the same thing to "C the complete nonsense" as Seebs has done to
Schildt.

This is getting out of hand...reviews of the review
of the book, truncated reviews of the review of the
book by somebody who's never read the book, now I'm
reviewing the truncated review of the review of the
book by somebody who's never read the book...what's
next, reviews of the review of the book by people
who've never read the review of the book?

I don't like libel laws

Great, I'll get to work on my web-site about
you, with your address and the libel that you
run a child prostitution ring from that address
(that's how the nutcases in misc.invest.stocks
roll, it's a lot of fun). You have a poor
understanding of how civilized modern societies
MUST function...

and I think threats of legal action are heavy-
handed, and not credible unless they come from the person allegedly
libelled himself.

In legal terms, nobody but the person libeled has
any "standing" to sue, which is just ONE of the
reasons that "SpinNosey" is so crazy with threats
lawsuits about stuff that's not about him...

However Nilges
is actually right, "C the complete nonsense" is a bad webpage and
should be either removed or substantially revised.

Well, on careful review, it seems to bear out what the
guys on TV said about everything on the web being a
bunch of crap, but whaddaya gonna do? Remove every
crummy ill-conceived poorly-written useless web-site
from the Internet, and Cisco would go out of business
in two days...

 

[Seebs]

The phrase "in general" is ambiguous; it can mean either "usually" or
"always". Assuming that "in general" was meant as "usually", he could
(and IMHO should) have mentioned that other representations exist.

Yes. At the time, I understood "in general" to mean "always" -- now that
I'm aware that it could be used either way, I'd probably phrase such
a criticism differently, although I stand by the substance of it.

And is therefore ambiguous, and therefore IMHO should be avoided in a
book that purports to teach C.

Or at least explained, or something.

In a quick reading, it appears to me that the first two listed errors
happen to be the least substantial.
Agreed.

I still don't see the relevance here, except in that it's probably a
reference to the neverending flood of threats of legal action Nilges
seems to generate.

This is true, I think -- and most significantly, *he does not care that
his books are wrong*. Or if he does, he's never admitted it, acknowledged
it, or responded positively to any kind of criticism that I'm aware of.
I did once get a very condescending fax full of badly-argued attempts to
justify his use of "void main". Was it sincere? That he stopped using
it in future books suggests that it was not -- it was offered only to make
the publisher feel like he didn't think he was wrong.

I disagree completely. "C: The Complete Nonsense" is a valuable
warning to those who might otherwise be misled by reading Schildt's
books. It could stand some revision, particularly an update to the
latest edition of the book.

The books don't seem to do as well now -- there hasn't been a new edition
for ten years, suggesting that it doesn't sell as well as the previous
ones. Partially, I suspect, because a large number of people now know
that Schildt's writing on C is atrocious.

-s

 

[Keith Thompson]

Yes. At the time, I understood "in general" to mean "always" -- now that
I'm aware that it could be used either way, I'd probably phrase such
a criticism differently, although I stand by the substance of it.

As a professional writer, Schildt should certainly be aware of the
ambiguity.

[...]

 

[Malcolm McLean]

No you couldn't, because when people say, "I could
go on", THEY NEVER CAN, they're just quitting while
they're ahead...

Next error: Schild writes printf("%f", sizeof(int)) and printf("%d",
sizeof(int));
The first is indisputably a real error. Without a copy of the book we
can't tell whether it is glitch - the cast somehow missed - or a more
serious error. The second is an error because of the vandalism wreaked
on the C language by size_t. The proposed fix printf("%lu", (unsigned
long) sizeof(int)) would be very confusing to beginners. However we do
have the first real errata entry.

Next error - sizeof() an array that is passed as a parameter. A real
error. This is a confusing and inconsistent backwater of C syntax,
however it is a real error and it should be picked up.

Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect. However we don't use natural language
in that very qualified, literal sense. Not a real error.

Next error: a variable referenced when scanf() fails. I don't have a
copy of the book. However whilst the result is undefined behaviour, in
practice what will always happen is that a calculations is made with a
garbage value. A real error, but not a serious one.

Next error: Schildt uses the terms "stack" and "heap". To be ultra-
correct, of course, we should talk of automatic and dynamic memory, or
whatever the C term is for the malloc() pool, I've forgotten myself.
But this is a classic case of demanding definitions where the author
intends to give an explanation.

So OK, there are a few real errors in Schildt's book which the webpage
picks up. But the rate of real errors to errors created by an
insistence on over-literal interpretations, and the rejection of any
type of simplification for the purposes of readability, isn't very
high. Only one error (the sizeof a parameter) so far is both
unambigiously real and presented in a manner that is fair to Schildt,
and the scanf() error is also real. We're up to page 131 and we've
found one glitchy page where everything seems to be going wrong with
sizeof(), and one minor bug in the use of scanf(). That doesn't seem
to me a particuarly bad error rate for a programming book.

 

[jacob navia]

Malcolm McLean a écrit :


[snip]

I don't like libel laws and I think threats of legal action are heavy-
handed, and not credible unless they come from the person allegedly
libelled himself. I suspect Schildt himself just regards this sort of
criticism as the inevitable concomitant of success. The books do very
well on the market, and no-one is forced to buy them. However Nilges
is actually right, "C the complete nonsense" is a bad webpage and
should be either removed or substantially revised.

I agree. When I presented sections of my tutorial here, some people
(heathfield, thompson and their acolytes) started destroying every
sentence with the peadntic remarks and style that seebs uses against schild.

Those people *need* to destroy to survive. The cult of pedantic
"correctness" over semantic understanding (you can't expect explaining
everything in a tutorial in the first page) and the desire to destroy
all work by people that doesn't belong to their group are their
principal characteristics.

I have been enduring those poeple for years (and I suppose I will have
to continue).

I find excellent that you stand against them.

jacob

 

[Keith Thompson]

Malcolm McLean a écrit :

[snip]

I don't like libel laws and I think threats of legal action are heavy-
handed, and not credible unless they come from the person allegedly
libelled himself. I suspect Schildt himself just regards this sort of
criticism as the inevitable concomitant of success. The books do very
well on the market, and no-one is forced to buy them. However Nilges
is actually right, "C the complete nonsense" is a bad webpage and
should be either removed or substantially revised.

I agree. When I presented sections of my tutorial here, some people
(heathfield, thompson and their acolytes) started destroying every
sentence with the peadntic remarks and style that seebs uses against schild.

No, we were trying to help you improve it. And my last name is
spelled with a capital 'T'; please treat it with the same respect
with which I treat yours.

Those people *need* to destroy to survive.

As long as you believe that, you will never understand what we're
trying to do here. I have no desire or ability to destroy you,
and I find your repeated claims that I do insulting.

The cult of pedantic
"correctness" over semantic understanding (you can't expect explaining
everything in a tutorial in the first page) and the desire to destroy
all work by people that doesn't belong to their group are their
principal characteristics.

I have been enduring those poeple for years (and I suppose I will have
to continue).

I find excellent that you stand against them.

Of course you do.

 

[jacob navia]

Keith Thompson a écrit :

No, we were trying to help you improve it. And my last name is
spelled with a capital 'T'; please treat it with the same respect
with which I treat yours.

So, let's make this clear:


(1) You have the right of treating me of "jerk" several times in public.
In this same group.

(2) I mustn't forget to capitalize the t of your name because if I do,
you feel upset.

I think that bothering to press the shift key is too much effort for
people like you. Either you accept the lower case or...

you learn how to use a killfile, that you brand here so often as a
"weapon".

I fear that you lack the mental abilities to do that though.

Good luck!

 

[Seebs]

Next error: Schild writes printf("%f", sizeof(int)) and printf("%d",
sizeof(int));
The first is indisputably a real error. Without a copy of the book we
can't tell whether it is glitch - the cast somehow missed - or a more
serious error. The second is an error because of the vandalism wreaked
on the C language by size_t. The proposed fix printf("%lu", (unsigned
long) sizeof(int)) would be very confusing to beginners. However we do
have the first real errata entry.

In context, it's clearly the more serious error -- no intent of casting,
just a plain typo.

I don't think size_t is at fault here -- I think the language is about
as sane as it can be given its requirements.

Next error - sizeof() an array that is passed as a parameter. A real
error. This is a confusing and inconsistent backwater of C syntax,
however it is a real error and it should be picked up.

That it is a confusing and inconsistent backwater is not a *mitigating*
factor; it is an *exacerbating* factor, making the error much more
serious.

It does, however, have room to get worse.

The original, from the 3rd edition:
/* Write 6 integers to a disk file. */
void put_rec(int rec[6], FILE *fp)
{
int len;

len = fwrite(rec, sizeof rec, 1, fp);
if(len != 1) printf("write error");
}

The description:
"Coded as shown, put_rec() compiles and runs correctly on
any computer, no matter how many bytes are in an integer."

This is a very well-written explanation of something which is totally
false.

So. Let's see how it gets fixed in the 4th edition:

/* Write 6 integers to a disk file. */
void put_rec(int rec[6], FILE *fp)
{
int len;

len = fwrite(rec, sizeof(int)*6, 1, fp);
if(len != 1) printf("Write Error");
}

This is a work of art. Schildt has replaced a very good example, which
would have illustrated something useful and interesting, with a very
bad example, which illustrates essentially nothing. This example no
longer tells you anything about sizeof().

If you wanted to make a good example, you could do something like:

int rec[6] = { 0, 1, 2, 3, 4, 5 };

len = fwrite(rec, 1, sizeof(rec), fp);
if (len != sizeof(rec)) printf("write error\n");

The problem is that, by declaring that we are writing a single object
of that size, Schildt has made it impossible to understand what's happening;
more useful by far would be to show writing a given number of bytes, not
a single object of some other size.

Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect. However we don't use natural language
in that very qualified, literal sense. Not a real error.

We do use natural language that way when we are writing a "reference".

Next error: a variable referenced when scanf() fails. I don't have a
copy of the book. However whilst the result is undefined behaviour, in
practice what will always happen is that a calculations is made with a
garbage value. A real error, but not a serious one.

Your "in practice... always" is vastly overclaimed.

Please do us all a favor, though, and write the guy treated with
THERAC-25 and let him know that calculations made with a garbage
value are "not a serious error".

Next error: Schildt uses the terms "stack" and "heap". To be ultra-
correct, of course, we should talk of automatic and dynamic memory, or
whatever the C term is for the malloc() pool, I've forgotten myself.
But this is a classic case of demanding definitions where the author
intends to give an explanation.

Except that the EXPLANATION IS WRONG.

That's the problem you seem to be missing. His explanation of the interaction
of these two kinds of memory is just plain useless in most cases, and flatly
wrong for a lot of systems. I haven't seen anything in years where you
can actually overrun program code or memory by filling up the stack.

So OK, there are a few real errors in Schildt's book which the webpage
picks up. But the rate of real errors to errors created by an
insistence on over-literal interpretations, and the rejection of any
type of simplification for the purposes of readability, isn't very
high.

Oversimplification for purposes of "readability", when it produces false
beliefs about a topic one is purporting to teach, is indeed a real error.

Only one error (the sizeof a parameter) so far is both
unambigiously real and presented in a manner that is fair to Schildt,
and the scanf() error is also real. We're up to page 131 and we've
found one glitchy page where everything seems to be going wrong with
sizeof(), and one minor bug in the use of scanf(). That doesn't seem
to me a particuarly bad error rate for a programming book.

But:
1. I wasn't listing everything up to that page; I was just listing things
that stuck out as interesting.
2. Getting everything wrong with sizeof() is a totally fatal flaw in a
book purporting to teach, or describe, C.
3. Your belief that the bug is "minor" is not supported by the evidence
of the real world.

Mostly, though... This was *typical*. The whole book is like this.

Okay, flipped to a random pgae.

#include <stdio.h>

void main(void)
{
char str[80];
freopen("OUTPUT", "w", stdout);
printf("Enter a string: ");
gets(str);
printf(str);
}

Let's see.

1. main declared incorrectly.
2. No error check for freopen.
3. No newline or flush for the prompt, so no guarantee that
it's actually been written.
4. Who cares whether it's flushed? If the freopen() succeeded,
"stdout" will now be the file OUTPUT, so the user won't see the
prompt anyway.
5. gets() is unsafe and should never be used on buffers, let alone
tiny buffers.
6. printf(str) can quite easily explode spectacularly if "str"
happens to have any format characters in it.

Seriously. Flip the book open to a random page, get garbage code.
Sure, you could argue that some of these don't have much of an
effect, but the net result is that there is no reasonable expectation
that the program will do what it is described as doing in a useful
way under any conceivable circumstances.

Oh, wait. I'm not even done. He then "explains":

In general, redirecting the standard streams by using freopen() is
useful in special circumstances, such as debugging. However,
performing disk I/O using redirected stdin and stdout is not as
efficient as using functions like fread() or fwrite().

This makes no sense. No hint is given as to what the difference
in "efficiency" might be.

This example, and description, are unchanged in the 4th edition.

-s

 

[Seebs]

I agree. When I presented sections of my tutorial here, some people
(heathfield, thompson and their acolytes) started destroying every
sentence with the peadntic remarks and style that seebs uses against schild.

I haven't seen it, but... I don't think you are quite understanding this.

Those people *need* to destroy to survive.

No.

You should have SEEN the floods of corrections I got from my tech reviewer
on some early drafts of my book. That happens. It's not "destroying" -- it's
what is necessary to make a good book possible.

The cult of pedantic
"correctness" over semantic understanding (you can't expect explaining
everything in a tutorial in the first page) and the desire to destroy
all work by people that doesn't belong to their group are their
principal characteristics.

There is no desire to destroy any work. I just want work to be *good*.
I would love to see a good, readable, and accurate C tutorial. I haven't
yet.

I agree that you can't explain everything in a tutorial on the first page.
I put a lot of blood, sweat, and tears into building a shell book which
is able to give a reader a decent overview of the shell, by picking easy
things to explain early, building on those, and... <drumroll> WARNING
THE READER WHEN I AM OVERSIMPLIFYING. With a forward reference to the
more detailed discussion.

I've not yet heard any complaints about that aspect of the book. There
are indeed errata (various typos, mostly, occasional historical errors),
but for the most part, it seems to be solid and usable.

Because I had a tech reviewer who was pedantic, thorough, and cared about
getting things right, not about making me feel good.

-s

 

[REH]

Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect.

Actual, the structure member operator is a postfix operator.

REH

 

[Ben Pfaff]

Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect.

Actual, the structure member operator is a postfix operator.

The structure member operator has two operands. That makes it a
binary operator.

 

[Keith Thompson]

Keith Thompson a écrit :

So, let's make this clear:

Yes, let's.

(1) You have the right of treating me of "jerk" several times in public.
In this same group.

I'm not sure what "treating me of" is supposed to mean. I understand
that English isn't your first language, and you're certainly
far better at it than I am at any language other than English,
so don't take this as a criticism. I *called" you an "arrogant
jerk" exactly once. Apparently you still haven't gotten over it.
At the time, I felt it was justified. We can discuss the reasons
further if you insist, but I'd prefer to let it drop.

(2) I mustn't forget to capitalize the t of your name because if I do,
you feel upset.

I calmly *asked* you to spell my name correctly, as a simple human
courtesy. I have consistently referred to you as "jacob" with a lower
case 'j' because that's how you sign your own name.

I think that bothering to press the shift key is too much effort for
people like you. Either you accept the lower case or...

No, pressing the shift key is not any significant effort at all. I'd
be glad to refer to you as "Jacob" rather than "jacob" if you ever
said that that's what you prefer.

you learn how to use a killfile, that you brand here so often as a
"weapon".

No, it's not a weapon, and I don't believe I've ever branded it as
one, but I'm certainly considering it.

I fear that you lack the mental abilities to do that though.

I'll read the rest of this thread before responding to that. In the
meantime, please consider whether you really want this discussion to
take place on that level.

Good luck!

Same to you.

 

[Ben Pfaff]

On Apr 5, 2:55 pm, Malcolm McLean <[email protected]>
wrote:
Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect.

Actual, the structure member operator is a postfix operator.

The structure member operator has two operands. That makes it a
binary operator.

It's a strange one. The right-hand operand can't be any conventional
expression. I wouldn't call it a proper binary operator.

And (having a quick look in the C99 reference) it does seem to be a
post-fix op followed by an identifier.

The structure member operator's second operand is unusual, but it
certainly has two. That makes it binary.

Whether it is a postfix operator is irrelevant, since that is an
orthogonal classification. I can imagine postfix, infix, and
prefix binary operators: e.g. 1 2 + versus 1 + 2 versus + 1 2.
(I'm not claiming that C has a binary operator with each kind of
syntax.)

 

[Keith Thompson]

Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect.

Actual, the structure member operator is a postfix operator.

The structure member operator has two operands. That makes it a
binary operator.

It's listed in C99 6.5.2 "Postfix operators".

The suffix of a "." operator isn't what I'd call an "operand".
The prefix is an expression. The suffix is not, and cannot be,
an expression.

One (IMHO reasonable) way to look at it is that ".foo" is a distinct
postfix operator for each member name "foo". That's how I tend
to think of it, but it does have the drawback of creating a nearly
unlimited number of operators.

Another way to look at it is that "." is a binary operator whose
right operand is special in that it must be a member name, not an
expression in its own right.

Another might be to treat it as a special syntactic form that isn't
really an "operator" at all.

The overriding consideration, IMHO, is that the C standard calls
it a postfix operator.

 

[James Harris]

....

Mostly, though... This was *typical*.  The whole book is like this.

Okay, flipped to a random pgae.

        #include <stdio.h>

        void main(void)
        {
          char str[80];
          freopen("OUTPUT", "w", stdout);
          printf("Enter a string: ");
          gets(str);
          printf(str);
        }

Let's see.

1.  main declared incorrectly.
2.  No error check for freopen.
3.  No newline or flush for the prompt, so no guarantee that
it's actually been written.
4.  Who cares whether it's flushed?  If the freopen() succeeded,
"stdout" will now be the file OUTPUT, so the user won't see the
prompt anyway.
5.  gets() is unsafe and should never be used on buffers, let alone
tiny buffers.
6.  printf(str) can quite easily explode spectacularly if "str"
happens to have any format characters in it.

Your web page is useful. Thanks for writing it. If Nilges causes you
genuine trouble at your publisher's - in other words they choose to
give him any credibility whatsoever - I'd be glad to send them some
comments to redress the balance.

That said, they should see him for what he is: a total kook with
personality problems.

James

 

[Keith Thompson]

On Apr 5, 2:55 pm, Malcolm McLean <[email protected]>
wrote:
Next error - "This shorthand [presumably +=, -=,*-, /=, %=, &= etc]
works for all the binary operators". Technically the structure member
operator is a binary operator, as are logical &&. So Schildt's
sentence is literally incorrect.

Actual, the structure member operator is a postfix operator.

The structure member operator has two operands. That makes it a
binary operator.

It's listed in C99 6.5.2 "Postfix operators".

The suffix of a "." operator isn't what I'd call an "operand".
The prefix is an expression. The suffix is not, and cannot be,
an expression.

[...]

I'm going to backtrack a bit. I hadn't realize that the C99 standard
has a definition for the word "operand". C99 6.4.6p2:

An _operand_ is an entity on which an operator acts.

There's no actual definition of "entity", but the implication is that
it's (at least) anything designated by an identifier. C99 6.2.1p1..2:

1 An identifier can denote an object; a function; a tag or a member
of a structure, union, or enumeration; a typedef name; a label
name; a macro name; or a macro parameter.
[...]

2 For each different entity that an identifier designates, the
identifier is _visible_ (i.e., can be used) only within a region
of program text called its _scope_.

So by my own argument (terms mean what the standard says they mean),
the member name following the "." operator is an operand.

The standard uses the phrase "binary operator" in several places, but
I don't believe it defines it or uses it in a section header.