C the complete nonsense
Malcolm McLean
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.
Richard Heathfield
> 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.
So what you're actually saying is that the first error is on the front
cover.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
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.
--
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
> 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
--
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!
Seebs
> Malcolm McLean wrote:
>> I think the title of Schildt's book invites misplaced criticism.
>> Whilst the book is entitled a "reference" it is in fact a tutorial.
> 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?
Bill Reid
wrote:
>
> 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...
---
William Ernest Reid
Richard Heathfield
<snip>
> "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.
My preference would be for each entry to state which edition of CTCR it
refers, and for a "Fixed in..." column to be added where appropriate.
That way, the site would serve all those unfortunate enough to have a
copy of CTCR, not just those with the latest edition.
Richard Heathfield
>> 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...
No. Malcolm's sentences are coherent, meaningful, and almost invariably
polite. He doesn't always think things through, he's by no means always
right, and I certainly don't always agree with him (in fact, for some
reason I rarely agree with Malcolm), but he's nothing like the moronic
bozo with whom you are endeavouring to compare him.
<rant snipped>
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.
>> 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.
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 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 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.
>> I suspect Schildt himself just regards this sort of
>> criticism as the inevitable concomitant of success.
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.
>> 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.
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.
Keith Thompson
> On 2010-04-04, Keith Thompson <ks...@mib.org> wrote:
>> 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.
As a professional writer, Schildt should certainly be aware of the
ambiguity.
[...]
Malcolm McLean
> On Apr 4, 1:54 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>
>
> No you couldn't, because when people say, "I could
> go on", THEY NEVER CAN, they're just quitting while
> they're ahead...
>
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
[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
>
> 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.
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.
Richard Heathfield
<snip>
> 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.
No, the second is an error because he got the format specifier wrong.
<snip>
Richard Heathfield
> 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.
I won't presume to speak for Keith, but what I did when you presented
sections of your tutorial here was point out some errors that you had
made. If you fixed those errors, good came out of the criticism - and
that was the intent. If you didn't fix the errors, why not?
> Those people *need* to destroy to survive.
No, those people are trying to improve the tutorial by pointing out
inaccuracies, *so that you can remove those inaccuracies*.
> The cult of pedantic
> "correctness" over semantic understanding
The cult of pretending it's okay to mis-teach your subject.
> (you can't expect explaining
> everything in a tutorial in the first page)
Of course not. But you don't have to be wrong on the first page, either.
> and the desire to destroy
> all work by people that doesn't belong to their group are their
> principal characteristics.
I have neither the desire nor the ability to destroy your tutorial. Only
you can do that.
> I have been enduring those poeple for years (and I suppose I will have
> to continue).
It would be better if you stopped enduring your critics and started
paying attention to them instead.
> I find excellent that you stand against them.
That doesn't surprise me in the slightest.
Richard Heathfield
> 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.
If you behave like a jerk, it is hardly surprising if, on occasion,
people call you a jerk.
> (2) I mustn't forget to capitalize the t of your name because if I do,
> you feel upset.
Getting people's names right is a matter of courtesy. Getting them wrong
is a matter of discourtesy. Consider how you would react if Keith
consistently referred to you as, say, "Nivia".
> I think that bothering to press the shift key is too much effort for
> people like you.
When I first read that sentence, I thought you were accusing Keith of
being too lazy to use the shift key appropriately. But now I realise
that what you really meant is that you don't think Keith is sufficiently
valuable for you to expend your valuable shift-key-pressing energy on
him. Such arrogance is staggering. I sincerely hope that the above is a
mis-translation of your real meaning, and that you did not intend to
come across as such a conceited moron.
> Either you accept the lower case or...
Oh, it's easy to accept that you're too stupid or too ill-mannered to
get his name right. What's harder to accept is that you desire to be
stupid or ill-mannered. But that does seem to be your intent.
> you learn how to use a killfile, that you brand here so often as a
> "weapon".
A killfile isn't a weapon. It's just a tool to filter out morons. Are
you suggesting that you're a moron?
> I fear that you lack the mental abilities to do that though.
Check your pronouns.
REH
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.
REH
Ben Pfaff
The structure member operator has two operands. That makes it a
binary operator.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Keith Thompson
> 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:
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.
bartc
"Ben Pfaff" <b...@cs.stanford.edu> wrote in message
news:87eiit3...@blp.benpfaff.org...
> REH <spam...@stny.rr.com> writes:
>
>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>> 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.
--
Bartc
Ben Pfaff
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
> REH <spam...@stny.rr.com> writes:
>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>> 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.
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
> Ben Pfaff <b...@cs.stanford.edu> writes:
>> REH <spam...@stny.rr.com> writes:
>>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>>> 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.
James Harris
By the way, it would be helpful if the page said at the top what
edition of the book it referred to. That doesn't diminish the
fundamental message to be wary of even well-known writers but it would
make it easier to cross check.
James
Ian Collins
>
> 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.
Try explaining that to a compiler. Programming is as much about
correctness as it is about clarity.
Where you get that weird notion about the desire to "destroy" from is
anybody's guess.
--
Ian Collins
Ben Pfaff
> Ben Pfaff <b...@cs.stanford.edu> writes:
>> REH <spam...@stny.rr.com> writes:
>>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>>> wrote:
>> The structure member operator has two operands. That makes it a
>> binary operator.
>
> It's listed in C99 6.5.2 "Postfix operators".
That's convenient, because it fits in the grammar at the same
level of precedence as the 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 form of "sizeof" does not take an expression as its operand.
Do you consider that form of "sizeof" a nullary operator? I have
not heard it described that way before.
[...]
> The overriding consideration, IMHO, is that the C standard calls
> it a postfix operator.
The C standard lists the "<" operator in a section titled
"Relational operators". Do you consider "<" to be a binary
operator?
Ben Pfaff
> 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.
I didn't know that either. Thanks for the information.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
>> Ben Pfaff <b...@cs.stanford.edu> writes:
>>> REH <spam...@stny.rr.com> writes:
>>>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>>>> wrote:
>>> The structure member operator has two operands. That makes it a
>>> binary operator.
>>
>> It's listed in C99 6.5.2 "Postfix operators".
>
> That's convenient, because it fits in the grammar at the same
> level of precedence as the postfix operators.
Are you suggesting that it's listed there *only* for convenience,
much as "typedef" is treated as a storage-class specifier?
Interesting, I hadn't thought of that.
>> 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 form of "sizeof" does not take an expression as its operand.
> Do you consider that form of "sizeof" a nullary operator? I have
> not heard it described that way before.
Hmm. I probably would think of it as a nullary operator if the
language didn't call it a unary operator.
> [...]
>> The overriding consideration, IMHO, is that the C standard calls
>> it a postfix operator.
>
> The C standard lists the "<" operator in a section titled
> "Relational operators". Do you consider "<" to be a binary
> operator?
Certainly.
It has a section called "Unary operators", so we can reasonably assume
that the unary operators are exactly those listed in that section.
(All the unary operators have the same precedence.) It doesn't have a
section called "Binary operators"; instead, the binary operators are
scattered across several sections. It also doesn't have a definition
of "binary operator", so we have to depend on common sense.
I'm a bit uncomfortable with "." being both a postfix operator and a
binary operator, but I can live with it.
Seebs
> On 5 Apr, 21:58, Seebs <usenet-nos...@seebs.net> wrote:
>> 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.
Thanks for quoting this, I missed one.
gets() strips a trailing newline, printf() does not add it, so the
material written to the output file may not be usable; as the default
mode in C is "text mode", the above opened stdout in text mode, and the
behavior of writing text with no line terminator to text mode is not
particularly well-defined.
(That said, I think the fourth edition does change this program; it's
now "int main" and ends with "return 0". None of the other issues are
addressed.)
> 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.
I appreciate the offer. I don't imagine it'll come up, but you never know.
Ben Pfaff
> It has a section called "Unary operators", so we can reasonably assume
> that the unary operators are exactly those listed in that section.
> (All the unary operators have the same precedence.)
Postfix ++ and -- each have one operand, yet they are not in the
"unary operators" section. (Maybe you consider that not an
exception because prefix ++ and -- are in the "unary operators"
section?)
> I'm a bit uncomfortable with "." being both a postfix operator and a
> binary operator, but I can live with it.
"Postfix" and "binary" are along two different orthogonal
classification axes. As far as I can tell, an operator can be
postfix, prefix, or infix independently of being unary, binary,
ternary, or N-ary. (I'm not sure that an unary operator can be
infix, unless parentheses for grouping is an example of an infix
unary operator.)
Seebs
> I'm a bit uncomfortable with "." being both a postfix operator and a
> binary operator, but I can live with it.
I'm not even entirely sure "operator" is the right name for it.
[] is a postfix-formed binary operator; it needs two things both of which
are values on which to operate. I'm not at all convinced that the structure
member things are exactly "binary operators" in the same sense.
REH
> The structure member operator has two operands. That makes it a
> binary operator.
Not according to the standard. It is classified as a postfix operator.
All binary operators using the E op E syntax, where E is an
expression. The member operator (also the indirection operator) can
only take an expression as the left-hand operator, like all postfix
operators. Its right-hand operand must be a member name.
REH
Keith Thompson
Please cite the section of the standard that says the right operand of
a "binary operator" must be an expression, or that an operator cannot
be both postfix and binary.
REH
> REH <spamj...@stny.rr.com> writes:
> > On Apr 5, 5:39 pm, Ben Pfaff <b...@cs.stanford.edu> wrote:
> >> The structure member operator has two operands. That makes it a
> >> binary operator.
>
> > Not according to the standard. It is classified as a postfix operator.
> > All binary operators using the E op E syntax, where E is an
> > expression. The member operator (also the indirection operator) can
> > only take an expression as the left-hand operator, like all postfix
> > operators. Its right-hand operand must be a member name.
>
> Please cite the section of the standard that says the right operand of
> a "binary operator" must be an expression, or that an operator cannot
> be both postfix and binary.
>
Show me an operator listed in the standard as a binary operator that
doesn't take expressions as both the left and right hand operator, or
one that is listed in both sections.
Mathematically, I would agree that the member operator is a binary
operator. But in C is a postfix operator, and the distinction is
relevant when writing a parser. If you've ever written a C parser, the
member operator parser perfectly as a postfix operator (with one extra
lexeme to the right of it), than some special form of binary
operator.
REH
Seebs
> Please cite the section of the standard that says the right operand of
> a "binary operator" must be an expression, or that an operator cannot
> be both postfix and binary.
Interestingly, the only time I see "binary operator" is by contrast to a
unary operator; thus, "binary +", "binary -", etcetera.
I think I'm going to concede this, based on:
6.5.2.3 Structure and union members
Constraints
1 The first operand of the . operator shall have a qualified or
unqualified structure or union type, and the second operand shall
name a member of that type.
If the second thing, which "shall name a member of that type", is an
"operand", then "." is a binary operator.
I think the use of "operand" is sufficient to make this unambiguous. My
instinctive dislike of calling it a "binary operator" is not enough to
win against the clear text of the standard.
REH
> I think the use of "operand" is sufficient to make this unambiguous. My
> instinctive dislike of calling it a "binary operator" is not enough to
> win against the clear text of the standard.
>
Really? I think the standard is quite clear that it is not (in the
sense of the language) a binary operator, unless someone on the
committee wants to chime in and tell me I am interpreting it wrong.
REH
Ben Bacarisse
> On 5 Apr, 00:48, Bill Reid <hormelf...@gmail.com> wrote:
>> On Apr 4, 1:54 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>>
>> > 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...
>>
> 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.
This same error occurs 6 times. At no point does the code from the
book show the beginner how to print a size correctly. The problem
isn't the one error as listed on Seebs's page, but that the book never
seems to tell the reader what they need to know. Sure, gloss over it
early on (though I'd not gloss over it like this) but at some stage
the correct way to print a size_t should be in a "complete reference"
to C.
(Somewhere in the 4the edition it must do so because the author will
have to describe the new printf format letters. No examples appear in
collected code, though.)
> 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.
If the book is a reference (as per the title) then "inconsistent
backwaters" have to be included. If it is a tutorial for beginners
(as you claim) why is this experienced writer including examples that
use "inconsistent backwaters" of the language? It is either an error
of fact or an error of style.
> 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.
What, I wonder, is a "real" error -- do you mean that you don't
consider it significant? I don't think it is all that significant
either except that it so easy to avoid. "This shorthand works for
many of the binary operators" or "this shorthand works for all the
arithmetic and bitwise binary operators" would both work, or the
author could simply state the combinations that are permitted.
There are more binary operators than more critics have mentioned.
This statement calls into question the meaning of >= and <= (which now
appear to be assignments) and is posits the existence of ===, !==, >==
and <== which don't exist.
> 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.
Except that, in what you call a tutorial, it is repeated time and time
again. I don't think there is a single example that tests the return
form scanf, fscanf or sscanf in the whole book. What a shame that
this tutorial never suggests the useful idiom:
if (scanf("what I want", &where, ...) == number_of_items) {
/* do stuff with my data... */
}
> 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.
I've commented on you comments just because I take a different view.
I fact I think this to-and-fro over the points in one commentary is
futile and not, ultimately, important.
Focusing on Seeb's web page misses the point. I, too, have not read
the book, but the code is on-line and the examples don't show C being
used well and wisely. This is a great shame in a popular book and is
(to my mind) far more significant than the details pointed out in the
error list. One can argue endlessly if such and such a detail is a
"real error" or not, but i don't think anyone who knows C can argue
the book presents C as it should be written.
There are 92 examples of using gets and quite a few examples of
unconstrained %s input formats. There are no examples of using the
return from scanf (and friends). And then there are some of the most
convoluted input loops I've seem since I stopped marking first year
students' work[1]. printf(s) (or the equivalent) occurs often. Not
every example is dangerous of course, but some are. Why get this
anti-pattern into your reader's heads when there is not need to?
In an error list, you can claim that reading into a char and then
testing it against EOF is a detail, but when that incorrect idiom is
repeated several times the reader will surely come to think that it is
correct and "how things should be done". Learners need to be told why
you read into a int, and not doing so at any point[2] is not a
simplification for the purposes of a smooth presentation of the
material -- it is a disservice to your readers.
If the author keeps passing one (or two) less than the size of the
array to fgets, readers will assume that you /need/ to do this. If
the text explains that you don't have to do this, then readers will be
puzzled by the examples that do. The best (simple) idiom for using
fgets with an array is
if (fgets(buf, sizeof buf, fp)) /* ... use it */
but that is never illustrated. Magic number sizes are used instead
and often odd ones to boot.
size_t values and objects are repeatedly treated as if they were ints.
You may disapprove of size_t, but someone learning C needs to know
what it is and how to use it correctly. Using strlen(s)-1 without
testing for empty strings and printing size_t values using %d (ten
times at least) just gives the confused idea that string lengths and
object sizes are ints when they are not. Learners deserve good,
clear, correct examples of how use these types, functions and
operators correctly.
Please, read the code (nearly 10,000 lines of it) and then report
back. I would be very surprised if you think that it presents
beginners in C with good, clear, correct examples of how to use the
language? That should be the real issue -- not whether this or that
error is a real error, a trivial error, or a serious error.
[1] For example:
char ch;
/* snip */
while(!feof(in)) {
ch = getc(in);
if(!feof(in)) putc(ch, out);
}
or:
while(!feof(fp)) {
fgets(str, 79, fp);
printf(str);
}
or:
char c;
/* snip */
do {
ch = getc(in);
/* snip */
if(ch=='\t') {
/* snip */
}
else {
putc(ch, out);
/* snip */
}
} while(!feof(in));
or:
while(*str) if(!ferror(fp)) fputc(*str++, fp);
or:
while(!feof(fp)) putchar(getc(fp));
[2] It may be explained in the test but if it is, why is it not there
in the code examples?
--
Ben.
Seebs
The term "binary operator" is never formally defined. As such, I'm
going to fall back on "a binary operator is an operator with two operands".
Since the name-of-a-member is the second of two "operands", the thing it is
an operand of is a binary operator.
bartc
"Seebs" <usenet...@seebs.net> wrote in message
news:slrnhrl0f4.n2f...@guild.seebs.net...
> On 2010-04-06, Keith Thompson <ks...@mib.org> wrote:
>> Please cite the section of the standard that says the right operand of
>> a "binary operator" must be an expression, or that an operator cannot
>> be both postfix and binary.
>
> Interestingly, the only time I see "binary operator" is by contrast to a
> unary operator; thus, "binary +", "binary -", etcetera.
>
> I think I'm going to concede this, based on:
>
> 6.5.2.3 Structure and union members
>
> Constraints
>
> 1 The first operand of the . operator shall have a qualified or
> unqualified structure or union type, and the second operand shall
> name a member of that type.
>
> If the second thing, which "shall name a member of that type", is an
> "operand", then "." is a binary operator.
>
> I think the use of "operand" is sufficient to make this unambiguous. My
> instinctive dislike of calling it a "binary operator" is not enough to
> win against the clear text of the standard.
The standard is being sloppy. The "." symbol is just a bit of syntax that
superficially resembles a proper operator.
But if you think that the "." symbol is an operator, because the standard
says it is, then that's fine...
--
Bartc
Seebs
> And then there are some of the most
> convoluted input loops I've seem since I stopped marking first year
> students' work[1].
> [1] For example:
> char ch;
> /* snip */
> while(!feof(in)) {
> ch = getc(in);
> if(!feof(in)) putc(ch, out);
> }
This one is, strictly speaking, at least correct. Mostly.
But why not write:
int ch;
while ((ch = getc(in)) != EOF)
putc(ch, out);
> while(!feof(fp)) {
> fgets(str, 79, fp);
> printf(str);
> }
This one, I'd point out, is essentially GUARANTEED to print the last
line twice. There is no way this code was ever tested.
> char c;
> /* snip */
> do {
> ch = getc(in);
> /* snip */
> if(ch=='\t') {
> /* snip */
> }
> else {
> putc(ch, out);
> /* snip */
> }
> } while(!feof(in));
This one will, in general, at least once putc(EOF).
(I'm assuming the "char c" and "putc(ch, ...)" is a typo from your post,
Ben? Or is that an even MORE obvious proof that this stuff never got
compiled?)
> or:
> while(*str) if(!ferror(fp)) fputc(*str++, fp);
The wrongness of this one is going to be non-obvious to many readers.
As long as you never have a write error, of course, this will work.
Think about what happens if you have a write error, though: When will
the loop terminate? You're never going to increment "str", because the
increment is inside a test against ferror(), which will just keep
returning true.
This is an exceptionally bad illustration of testing an error.
> or:
> while(!feof(fp)) putchar(getc(fp));
Same deal as the other one; will putchar(EOF) at least once.
And this seems to be *consistent* -- all of the code is crap.
Ben Bacarisse
> On 2010-04-06, Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> And then there are some of the most
>> convoluted input loops I've seem since I stopped marking first year
>> students' work[1].
>
>> [1] For example:
>
>> char ch;
>> /* snip */
>> while(!feof(in)) {
>> ch = getc(in);
>> if(!feof(in)) putc(ch, out);
>> }
>
> This one is, strictly speaking, at least correct. Mostly.
>
> But why not write:
>
> int ch;
> while ((ch = getc(in)) != EOF)
> putc(ch, out);
>
Yes, there was no claim that this is wrong, just convoluted. It is a
shame that the book does not present a clear and simple pattern for
using the various input primitives correctly.
I worried that by citing more code my point would get diluted. I
don't mind an error or two. I don't mind the odd idiosyncratic usage.
What I mind is the absence of good advice on (and examples of) how to
use the various input functions correctly:
That you read characters into an int (or a wint_t if you are using
wide characters) and test for EOF (or WEOF); that you test the result
of fgets in the loop; that you test the result of scanf (and friends)
for success rather than failure, and so on. C was designed to be used
in a particular way and to fight against that gives rise to obtuse and
(in some cases) erroneous code.
<snip detailed discussion>
> And this seems to be *consistent* -- all of the code is crap.
I'd rather not say that. In all seriousness, I don't know what the
criteria are for "crap" code -- it means different things to different
people. Going simply by the code examples, the reader will not learn
how to use C simply and correctly and that means that I could not
recommend the book at anyone learning C. That, ultimately, is what
matters.
--
Ben.
Seebs
> Seebs <usenet...@seebs.net> writes:
>> On 2010-04-06, Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>> And then there are some of the most
>>> convoluted input loops I've seem since I stopped marking first year
>>> students' work[1].
>>> /* snip */
>>> while(!feof(in)) {
>>> ch = getc(in);
>>> if(!feof(in)) putc(ch, out);
>>> }
>> This one is, strictly speaking, at least correct. Mostly.
> Yes, there was no claim that this is wrong, just convoluted. It is a
> shame that the book does not present a clear and simple pattern for
> using the various input primitives correctly.
Right. I was pointing it out, not because I thought you thought otherwise,
but because it was unusual in that it didn't actually do anything
obviously incorrect, it was just clumsy.
> I worried that by citing more code my point would get diluted. I
> don't mind an error or two. I don't mind the odd idiosyncratic usage.
What I mind is that:
1. Every usage is idiosyncratic.
2. More examples seem to be buggy than not, at least of those you
found.
> What I mind is the absence of good advice on (and examples of) how to
> use the various input functions correctly:
Agreed.
>> And this seems to be *consistent* -- all of the code is crap.
> I'd rather not say that. In all seriousness, I don't know what the
> criteria are for "crap" code -- it means different things to different
> people. Going simply by the code examples, the reader will not learn
> how to use C simply and correctly and that means that I could not
> recommend the book at anyone learning C. That, ultimately, is what
> matters.
What I mean by "crap" is that a large number of the examples are
sufficiently poorly-written that I would not expect them to pass any
halfway-decent code review. They are bad examples, they don't
illustrate the points they're supposed to, they don't illustrate how
to do these things expressively or cleanly... It's not useful as
teaching material.
Lorenzo Villari
Maybe from Nilges, maybe from Han from China, maybe from both...
Bill Reid
> On 2010-04-05, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
>
> > 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.
>
> factor; it is an *exacerbating* factor, making the error much more
> serious.
>
Well, of course, except for people with "SpinNosey" "logic",
which is apparently "catching"...
> 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."
>
Well, for people with "SpinNosey" "logic", it WOULD
compile and run "correctly" (without crashing), so,
NOT AN ERROR!!!
> This is a very well-written explanation of something which is totally
> false.
>
Impossible...if it's "clear" it must be correct...
> 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.
If we define "art" as "not knowing "C" from a
hole in the ground"...
> 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().
>
Was THAT the point of the "example"? I thought it
was how NOT to work with arrays passed as parameters
to a function...now THAT would have been useful...
> 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.
>
OK, I'm about to go on another mini-"rant", as "HeathenFeld"
would describe it, about technical "tutorials". I'll
keep it short, though, and just say another GIGANTIC
problem with most books is the fallacy of EXAMPLE IN
LIEU OF EXPLANATION. Hopefully, the problem I'm alluding
to is self-evident, and is all the more damaging when
"describing" "C", since many TERRIBLE "examples" COULD work
some times but not at others, and rarely will illustrate
the important underlying principle...
---
William Ernest Reid
spinoza1111
> On 2010-04-06, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > Seebs <usenet-nos...@seebs.net> writes:
I shall rejoin this discussion prematurely to support Jacob and
Malcolm. "Cease-fire" is over a bit early, I'm afraid. I wanted, in
part, to see if things would "quiet down" if I suspended
participation, but when Malcolm, admittedly on my request, posted the
issue blew up, with undeserved attacks on his credibility.
Peter, the issue here isn't Schildt's book. It is "C: the Complete
Nonsense", not "C: the Complete Reference".
Even if all of what you say is true (and on specific errata you are
right), it doesn't add up to a proper critique, furthermore, it has a
silly and extreme attitude about "bad" books.
I have shown you, in a manner independent of big-E (where big-E is the
total number of errors in Schildt's book, your book, Heathfield's
book, or my book), that you don't even approximate the big-E for
Schildt. You have had 15 years to do this, and you failed. Therefore,
you need to withdraw the complaint. I will take responsibility for
repairing wikipedia after you do so in a manner that will not mention
your part in this rather sordid affair, but someone else will have to
change the C FAQ.
Furthermore, you have a strange and troubling intolerance about "bad"
books, whereas cultivated people normally have libraries filled with
incunabula and curiosities, including many books with "errors".
For example, Ayn Rand published an extremely silly book, "Notes for
the New Intellectual", in 1961. Sydney Hook, a real philosopher with
real credentials, showed in detail how Rand made several basic errors,
but at no time did he call for NFTNI to be pulped.
>
> -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!
Keith Thompson
> On 2010-04-06, Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> And then there are some of the most
>> convoluted input loops I've seem since I stopped marking first year
>> students' work[1].
>
>> [1] For example:
>
>> char ch;
>> /* snip */
>> while(!feof(in)) {
>> ch = getc(in);
>> if(!feof(in)) putc(ch, out);
>> }
>
> This one is, strictly speaking, at least correct. Mostly.
Does your use of "Mostly" refer to the fact that the code will go into
an infinite loop on an input error?
> But why not write:
>
> int ch;
> while ((ch = getc(in)) != EOF)
> putc(ch, out);
Right. Apart from being both clearer and more idiomatic, it
doesn't misbehavie *too* badly on an input error. (Ideally it
should probably report the error somehow, but leaving that out in
a tutorial is understandable.)
Seebs
> an infinite loop on an input error?
No, it refers to me having missed that. Good catch.
That's why Schildt's books are so bad -- the code is sufficiently badly
broken that several skilled professionals looking at it can *miss* some of
the errors, because they're masked by others.
spinoza1111
> Malcolm McLean wrote:
> > 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.
>
> So what you're actually saying is that the first error is on the front
> cover.
If you wrote, or edited, C Unleashed, you'd know that the author is
not in charge of the cover material.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within
spinoza1111
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
> > I've been asked by Edward Nilges to comment on this webpage.
>
Bite me, Snidely.
>
> > 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?
It is in line with the ordinary usage of hard-working programmers who
mean by a USEFUL reference, a book which covers all issues but in a
usable way. The Standards document is a "reference" in a different and
legalistic sense. Kernighan and Ritchie is not a reference.
>
> > 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.
No, a brilliant teacher can make errors in detail. In fact, the best
are often admit doubt and error. Einstein in particular stumbled in
math, according to his 2007 biographer Walter Kauffman.
Sitting in front of, and auditing, a teacher who is always right is
neither a necessary nor a sufficient condition for learning.
Confucius asked more questions than he gave answers.
You are correct, however, in saying that there would be no harm in
correcting Schildt. But CTCN fails to do this in relation to its
implication that there are "hundreds" (n>100) or "dozens" (n >
approximately 48) errors. And CTCN, not CTCR, is the problem here.
Furthermore, to the ordinary, hard-working programmer, C then and now
constitutes a language with many different dialects. A Platonic idea
of absolute truth as regards such a gelatinous artifact as C does not
exist. Instead, everyday pragmatism (is the book useful) applies, and
this is ordinarily verified by what the free market says. In the free
market, the book went to four editions. Case closed.
>
> [...]
>
> > 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.
That's just wrong. The only use of "general" to mean "always" is in
formal logic, which is signally misleading as regards English usage
(as in the case of the false belief that in ordinary language anything
can be clear and wrong). A logical "generalization" is a statement
symbolized (x)[P(x)] which is true for all x.
In ordinary English usage, however, "in general" means "usually".
>
> > 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.
Sez who? My experience in the corporation is that newbie C
programmers, especially in financial firms, fail to have a computer
science background save in "rocket science" on Wall Street, not, in my
experience, in credit scoring on LaSalle Street. They need to learn
important CS distinctions before language law.
>
> > 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?
Blow me. I then treated ALL of CTCN, point by point and as usual
you're lying here.
>
> 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.
You don't know this, and there is no confirmation of your theory in
the noncode text.
Furthermore, the issue isn't Schildt: it's Seebach. He's plainly
incompetent as a C programmer according to the evidence he's posted
and CTCN is inadequate.
>
> 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.
Again, misuse of ill-understood and second-hand concepts from formal
logic to criticise ordinary English shows that you understand neither
formal logic nor English, which is a common failure of incompetent
programmers. Just as "clear but wrong" is a solecism except when
applied to relatively uninteresting analytic falsehoods expressed in
formal language, and just as you confused the English phrase "in
general" with universal quantification in formal logic, here you rely
on the overgeneral, logical fact that the English copular verb "is"
can mean logical identity OR subset inclusion to buttfuck "is" into a
true interpretation.
However, a literate person knows how to disambiguate "is", as do
literate OO programmers, who use "is-a" to show subset in inheritance
as opposed to "has-a" to show reference to an object, and "==" in C
Sharp in Java to show identity.
The rule is that for "a is b", if a names a class with > 1 members n
or (in "the 'heap' is a DOS term") a unit set of one member
coextensive with the member, and b obviously names a class with m>n
members, then its being stated, formally, that a is either a member or
a subset of b.
Whereas when a and b are at the same level, if they are both singular
things or unit sets, or sets of roughly equal cardinality, "a is b"
asserts "a==b".
Since there are many "DOS terms" whereas "the heap" is one "term",
Seebach was asserting, wrongly, that the word "heap" is used only in
reference to MS-DOS.
You barbarize language to be right.
The only thing that you say that's true is that "the 'heap' is not a C
term". No, it isn't. But it is impossible, an ignotus per ignotum
(explaining the unknown using the unknown) to "teach" C using only C
terms. As I have said, Herb was describing an instance of runtime in
the same way the high school teacher illustrates the Pythagorean
theorem using chalk.
>
> (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.)
That is unfortunately true, and a concern of mine. I would be
delighted if you downloaded Microsoft .Net Visual Basic Express and my
compiler for Quickbasic written for my book "Build Your Own .Net
Language and Compiler", and analyzed my code for errors since this
would increase my sales and make me money..."there is no such thing as
bad publicity".
But the problem at this time is not Schildt, it is Seebach, who has
fraudulently based his career in some measure on a document that is
far more flawed than Schildt.
The ball is in your court, and that of Seebach. You can end this,
including the troubling information that has emerged about Seebach's
competence, by encouraging Peter to simply withdraw the document and
substituting a blank page. If he does so, I will not post on this
issue. At this point, to spare Schildt further anguish, I waive my
request for an apology.
>
> > 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.
To believe that anyone can be "misled" by a book is Fascism. I was
assigned Sherman's "Programming and Coding for Digital Computers" in
my first computer science class. It described the IBM 7094 computer, a
fixed word length, single address mainframe with a 36 bit word. The
computer the class used was the IBM 1401, a "variable word length",
two address mainframe. I failed to attend the lecture in which the
professor explained this, sharing some of Peter's intellectual vanity
when I was 20.
Because Sherman provided no clue on 1401 machine language programming
for the first assignment, I bought a separate McGraw Hill book on the
1401 and a 1401 reference manual from the IBM shop in the IBM building
which used to be on the Chicago river.
However, despite the fact that Sherman was globally wrong in relation
to our needs, I read it from cover to cover several times and it was
valuable, since it, and not the McGraw Hill book or the IBM manual,
described how a computer could simulate another. It also explained
floating point, and a number of other computer science topics.
The worst books on "programming" (where "programming" books bear an
ambiguous and rather louche relationship to computer science) I ever
saw were written by the manager in the computer center at my uni. They
concerned a forgotten mini-mainframe, the IBM System/3 of 1970, which
was intended for small and medium businesses so IBM could stop
supporting the extremely popular 1401.
This manager was a nice guy, if stuffy and pompous to a fault; a
former IBMer, he wore blue suits and pocket hankies. Once he got a
load of my long hair and antiwar armband, he was hostile until he
happened to pick up a listing of my assembler code, and liked the
facts that on each side of each line I had a literate comment and that
the code was great.
This was because we were both of Irish Catholic educated background
and were both verbose...he perhaps to a fault, since his books were
absurdly stuffy and pompous in tone. Many people think there's nothing
more stuffy and pompous than my own prose, but he broke the mold.
After he discovered my list he was much kinder, but still advised me
to get a haircut.
His books were "bad" in your sense. But intelligent people never use
the mental model in which one can be misled by a book. That in fact
was the philosophy behind the Catholic Church's "index of prohibited
books" which is no more. A grown up knows that it is his
responsibility to evaluate all books fairly. A grownup programmer
tests code snippets, and treats time taken to correct the creator's
mistake as a valuable time for learning.
Look at
http://www.cvm.qc.ca/gconti/905/BABEL/Index%20Librorum%20Prohibitorum-1948.htm
This is the Catholic Church's "Index of Prohibited Books" in 1948.
Here are entries for Spinoza:
Spinoza, Benedictus de Tractatus theologico-politicus, continens
dissertationes aliquot, quibus ostenditur libertatem philosophandi non
tantum salva pietate et reipublicae pace posse concedi, sed eandem
nisi cum pace reipublicae ipsaque pietate tolli non posse. 1679
Spinoza, Benedictus de "Opera posthuma." 1690
Imagine what it would mean for someone to find himself on this index.
How they feel.
I'm afraid that for you, technology has been marked-off as a laager or
zone of control in which you don't have to intellectually mature, and
can practice out of date habits of intolerance. And I'm afraid that
given your approval of a buggy off by one strlen last month, this
intolerance does not imply competence.
spinoza1111
> On 2010-04-04, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
snip snip snip
> 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.
I think that they were, in actuality, Microsoft people whom you
bullied, since Schildt is Microsoft centric. Neither you, nor Richard,
nor Kiki give any evidence of teaching or programming competence.
>
> > 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.
Actually, "in general" was both true and useful. As I have said, real
programmers are mostly, and perhaps unfortunately, like you: they
didn't take CS. In your case, the failure is inexcusable, since Mommie
and Daddy, in your case, sent you to university. In the case of a
programmer in credit scoring on LaSalle Street in Chicago, the failure
may be excusable because Daddy left and Mommie struggled to support
him.
But in either case, you'd have learned in class that it's more
important to first learn that most modern machines use twos complement
than the language law of C, since they are learning CS in parallel
with a programming language. You act so precious about the laws of C,
but have nothing but contempt for wider rules.
>
> > 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.
"Massively" in upper case? You haven't made your case. You listed
twenty "errors" only 6 of which we have confirmed.
>
> 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?
He did this in code, not in discussion.
>
> > 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.
Wow. The hypocrisy. Oh the hypocrisy. Peter, you cherry picked twenty
trivial things out of a large book because you had no qualifications
worth note as a programmer, thinking that if you trashed Schildt, you
would magically be qualified.
> 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
> --
Richard Heathfield
<snip>
> I shall rejoin this discussion prematurely
Prediction fulfilled. (See Message-ID:
<quqdnVofP5fuDSXW...@bt.com> for details.)
> to support Jacob and Malcolm.
If they're not capable of arguing a point without help, then there's
something wrong with their argument.
> "Cease-fire" is over a bit early, I'm afraid. I wanted, in
> part, to see if things would "quiet down" if I suspended
> participation, but when Malcolm, admittedly on my request, posted the
> issue blew up, with undeserved attacks on his credibility.
I see no attacks on Malcolm's credibility in this thread. I do see some
fairly hefty attacks on his argument, but that's only because his
argument is broken.
> Peter, the issue here isn't Schildt's book. It is "C: the Complete
> Nonsense", not "C: the Complete Reference".
The one is a commentary on the other. Therefore, both are relevant to
the thread.
> Even if all of what you say is true (and on specific errata you are
> right), it doesn't add up to a proper critique,
If on specific errata he is right, it adds up to a proper critique,
unless there are a significant number of specific errata that he got
wrong. This you have failed to demonstrate.
<nonsense snipped>
> I will take responsibility for
> repairing wikipedia
No wonder it has such a bad reputation, if people like you are
"repairing" it. But I thought you'd been banned from "repairing" Wikipedia?
<snip>
spinoza1111
> >> 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.
>
>
> > The structure member operator has two operands. That makes it a
> > binary operator.
>
>
> The prefix is an expression. The suffix is not, and cannot be,
> an expression.
>
> 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.
>
> 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"
OK, so structure dot is NOT a "binary" operator. Likewise, in certain
contexts, "binary" means "arithmetic" and not logic.
You and Peter seem to be unclear on many issues on formal logic which
coupled with your deficiencies in English means that you're signally
uneducated. One is the distinction between language and meta-language.
In a metalanguage, the meaning of "binary operator" can change as we
see here.
spinoza1111
> On 04/ 6/10 07:23 AM, jacob navia wrote:
>
>
>
> > 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.
>
> Try explaining that to a compiler. Programming is as much about
> correctness as it is about clarity.
Not in practice. With all this talk about "precision" and
"correctness", the track record of programmers has been laughable.
A compiler is not something to which anything is "explained".
>
> Where you get that weird notion about the desire to "destroy" from is
> anybody's guess.
>
> --
> Ian Collins
spinoza1111
> Keith Thompson <ks...@mib.org> writes:
> > Ben Pfaff <b...@cs.stanford.edu> writes:
> >> REH <spamj...@stny.rr.com> writes:
> >>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
> >>> wrote:
> >> The structure member operator has two operands. That makes it a
> >> binary operator.
>
> > It's listed in C99 6.5.2 "Postfix operators".
>
> level of precedence as the 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.
>
> Do you consider that form of "sizeof" a nullary operator? I have
> not heard it described that way before.
>
> [...]
>
> > The overriding consideration, IMHO, is that the C standard calls
> > it a postfix operator.
>
> "Relational operators". Do you consider "<" to be a binary
> operator?
Way to go Ben. Kicking the ball towards our goal. You're the wee man,
you are.
"Binary operator" does not have, any more than many English
expressions, a fixed meaning. In the context, Herb meant "binary
arithmetic operator" since K & R thought it would be cool to combine
simple and common arithmetic operators with assignment, but not so
cool to do this for logic operators.
spinoza1111
> On 2010-04-05, James Harris <james.harri...@googlemail.com> wrote:
>
>
>
>
>
> > On 5 Apr, 21:58, Seebs <usenet-nos...@seebs.net> wrote:
> >> 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.
>
> Thanks for quoting this, I missed one.
>
> gets() strips a trailing newline, printf() does not add it, so the
> material written to the output file may not be usable; as the default
> mode in C is "text mode", the above opened stdout in text mode, and the
> behavior of writing text with no line terminator to text mode is not
> particularly well-defined.
>
> (That said, I think the fourth edition does change this program; it's
> now "int main" and ends with "return 0". None of the other issues are
> addressed.)
>
> > 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.
>
> I appreciate the offer. I don't imagine it'll come up, but you never know.
How would we know that CTCN is useful.
"Duh, I didn't know C too good because I read Schildt but then I read
CTCN and I'se seen da light".
This model simply doesn't apply. Instead a competent programmer (who
is in fact an extremely rara avis or rare bird in developed countries)
would learn from experience, merely supplemented by interaction with
texts, that MS DOS or Windows C is very different from unix or linux
C.
In the linux world, he would indeed be careful to int the return of
main.
In Windows, he would see no need because in Windows we can't plug
stuff together in the way we did on unix.
My experience in Asia is that most computer books are prohibitively
priced in relation to Asian programmer salaries, yet they are more
competent than programmers in America or Britain. A book by itself can
neither make nor unmake a competent programmer.
Seebs
> spinoza1111 wrote:
>> I shall rejoin this discussion prematurely
> Prediction fulfilled. (See Message-ID:
><quqdnVofP5fuDSXW...@bt.com> for details.)
I think that's shooting fish in a barrel territory.
> I see no attacks on Malcolm's credibility in this thread. I do see some
> fairly hefty attacks on his argument, but that's only because his
> argument is broken.
And also a bit of concern about why he would jump in and make silly
claims ("it's a tutorial, not a reference" -- HUH?!).
>> Peter, the issue here isn't Schildt's book. It is "C: the Complete
>> Nonsense", not "C: the Complete Reference".
> The one is a commentary on the other. Therefore, both are relevant to
> the thread.
Yes. The commentary can only be evaluated in terms of the thing commented
on.
> If on specific errata he is right, it adds up to a proper critique,
> unless there are a significant number of specific errata that he got
> wrong. This you have failed to demonstrate.
I think there's certainly a meaningful sense in which it's not a
"proper critique"; if I went to someone for a professional-quality
book review, and got back C:TCN, I'd be upset.
But as things posted on the internet for free roughly 15 years ago go,
it's not bad.
>> I will take responsibility for
>> repairing wikipedia
> No wonder it has such a bad reputation, if people like you are
> "repairing" it. But I thought you'd been banned from "repairing" Wikipedia?
Well, yes. The purpose of this whole thing seems to be that the Wikipedia
admins chose to accept the C:TCN page as sufficient evidence that the
"controversy" section deserved to be there. Thus, if Nilges can get enough
people to argue that C:TCN isn't a very good critique... nothing happens.
Because the underlying point isn't anything to do with C:TCN. It's that
the page is an *example* of the general category of "reputable C experts who
have served on the committee pan Schildt's work". Clive's commentary would
do just as well. For that matter, even if C:TCN went away, it wouldn't
change the fact that I'm quite clearly on the record as stating that the
book is junk that I would never inflict on someone trying to learn C.
If people really care, hey, I can always do a proper critique. I've got
another ~15 years of writing and programming experience to draw on since
the days when I wrote C:TCN. That said...
If I were to write such a page today, based on the 4th edition, it would have
fewer nitpicking errors, but I could do a much better job of explaining in
detail, and presenting effectively, the case that the remaining errors both
conceptual and technical are serious enough to utterly dispel any notion
that the book ought to be used to learn from. I know a lot more about
writing, and about how to teach people about computers, and about C, than I
did back in ~1995 or so. My impressions of Schildt's work have not changed
for the better.
-s
--
spinoza1111
> REH <spamj...@stny.rr.com> writes:
> > On Apr 5, 5:39 pm, Ben Pfaff <b...@cs.stanford.edu> wrote:
> >> The structure member operator has two operands. That makes it a
> >> binary operator.
>
> > Not according to the standard. It is classified as a postfix operator.
> > All binary operators using the E op E syntax, where E is an
> > expression. The member operator (also the indirection operator) can
> > only take an expression as the left-hand operator, like all postfix
> > operators. Its right-hand operand must be a member name.
>
> Please cite the section of the standard that says the right operand of
> a "binary operator" must be an expression, or that an operator cannot
> be both postfix and binary.
Oh the post-humanity...oh the autism...
spinoza1111
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
...snip Malcolm and Ben's acute commentary...
Ben, with your usual care, you have shown that there are many errors
in Schildt as there often are in computer books and especially online.
These errors are exacerbated by the fact that C was not designed for
Ms DOS but for unix. Arguably it is best used with unix, as my
experience with Nash (who was using C on MS DOS and has converted to
Mathematica) shows.
But: the problem here is Seebach, who did nothing like your homework
but who has become the sole source of a charge that has been
globalized to all of Schildt's output and which has unnecessarily
harmed him. He's the zero-cite, not you.
Your honesty and your competence is such that I believe that if you
and not Seebach had posted CTCN, you would have posted ALL errors you
found, and you would have said, explicitly, that your concern was ONLY
this book. You would have concluded that it is useful to MS DOS
programmers but not "recommended" for prospective unix or linux
programmers.
But this isn't what has happened. This is why Seebach needs to replace
CTCN with a blank document or a picture of a bunny.
Richard Heathfield
spinoza1111 wrote:
> On Apr 5, 5:00 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Malcolm McLean wrote:
<snip>
>>> I think the title of Schildt's book invites misplaced criticism.
>>> Whilst the book is entitled a "reference" it is in fact a tutorial.
>> So what you're actually saying is that the first error is on the front
>> cover.
>
> If you wrote, or edited, C Unleashed, you'd know that the author is
> not in charge of the cover material.
Having been involved from the very beginning in the design of "C
Unleashed", I knew the proposed title right from the outset, because it
was given to me in the email in which I was first asked to get involved
with the project. I also knew I couldn't change the title, even though I
wasn't very happy with it. So, instead, I inserted some text into the
book that pointed out the issue I had with the title, the finding of
which I will leave as a not-very-difficult exercise.
Here is a quote from Schildt's preface:
"I had been given the mission of creating a complete reference guide to
the C programming language. Not just /any/ book, but the /complete/ book."
So Schildt thinks it's a reference book. For Malcolm to be right,
Schildt has to be wrong. And if Malcolm is wrong, then Schildt is
/still/ wrong because the book is clearly /not/ a "complete reference",
nor even an adequate one.
Let's play the random game again.
Okay, this is from page 420 of the second edition of CTCR, not a page I
recall seeing before. It is discussing the _dos_read function, which
Schildt rightly points out is not part of the C language proper, but
"only applies to DOS-based C compilers" (and by no means all of them, he
fails to say, but he does add "It may also have a slightly different
name, so check your user's manual". So let's cut to the code:
Example
This fragment reads up to 128 characters from the file described by fd:
unsigned count
char *buf[128];
if(_dos_read(fd, buf, 128, &count))
printf("error reading file");
In those four lines of code, I can see three bugs without even trying.
The missing semicolon will of course result in a diagnostic message from
the compiler. The missing newline escape sequence may result in the
error output not appearing immediately (or indeed at all, if it's the
last data written to that stream before program termination). But most
importantly, the array is of 128 char *, whereas it should be of 128
char. He is reading arbitrary byte values into an array of pointers!
But the worst mistake of all is not a bug in the sense that it's a code
error. The worst mistake is that he utterly fails to explain why anyone
would ever bother to use this function, given the availability of fread.
I'm not saying no such reason exists. I'm saying he fails to give it.
Seebs: was this corrected in CTCR3?
spinoza1111
> On 2010-04-06, Keith Thompson <ks...@mib.org> wrote:
>
> > Does your use of "Mostly" refer to the fact that the code will go into
> > an infinite loop on an input error?
>
> No, it refers to me having missed that. Good catch.
>
> That's why Schildt's books are so bad -- the code is sufficiently badly
This is the sort of irresponsible statement that is legally actionable
on your part. Schildt is unlike you an educated generalist who focuses
on Microsoft but also, whether you like it or not, has linux and unix
experience. My experience at Bell Northern Research is that people who
in fact failed to become educated in computer science often learned
unix only and saw everything through a distorted unix lens, in the
same way old IBM 1401 programmers wanted everything to be a 1401 ever
after, and C++ programmers try to code C++ as C.
"Schildt's books are so bad" is libel. He's published a lot more than
you have because his educational background allows him to ascribe
unfamiliar features of a new platform urbanely and civilly to his own
ignorance. Based on finding 6 errors and inflating them to only 20,
you've made an absurd generalization.
> broken that several skilled professionals looking at it can *miss* some of
> the errors, because they're masked by others.
>
> -s
> --
Phil Carmody
> Malcolm McLean <malcolm...@btinternet.com> writes:
[SNIP - countering PS's C:TCN]
> 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.
When I first learnt C, it was being called the "free store" or
something so similar my memory cannot distinguish it. Given that
the 'heap' isn't structurally or algorithmically a 'heap', I always
wondered why a less baggage-laden term wasn't more popular.
This is probably an issue for a.f.c, though.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
Richard Heathfield
> And I'm afraid that
> given your approval of a buggy off by one strlen last month, this
> intolerance does not imply competence.
gets(s);
if(*s==0) break; /* no entry */
p = malloc(strlen(s));
if(!p) {
printf("out of memory.\n");
return;
}
strcpy(p, s);
Code taken from p550 of CTCR, 2nd edition.
Richard Heathfield
> On Apr 5, 6:57 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-04-04, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
>
<snip>
>>> 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.
>
> "Massively" in upper case? You haven't made your case. You listed
> twenty "errors" only 6 of which we have confirmed.
Random quote from CTCR 2nd edition. This is from p241:
The remove() function erases the specified file. Its prototype is
int remove(char *filename);
The error is, I hope, obvious enough that I don't have to point it out.
No? Okay, I'll tell you. The prototype is actually:
int remove(const char *filename);
and the difference is significant. For example, the const means we can
do this:
if(remove(fname) == 0)
{
if(rename(tname, fname) == 0)
{
/* update of original file with original name was successful */
}
else { /* recover */ } } else { /* recover */ }
Without the const, we would have no guarantee that fname remained
unchanged (the ISO C Standard contains no explicit guarantees to that
effect in the descriptive text that follows the synopsis of either
remove() or rename()), so we'd have to make a safe copy first. But the
const means we don't have to do that.
<snip>
Richard Heathfield
<snip>
> Your honesty and your competence is such that I believe that if you
> and not Seebach had posted CTCN, you would have posted ALL errors you
> found,
Life's too short.
> and you would have said, explicitly, that your concern was ONLY
> this book. You would have concluded that it is useful to MS DOS
> programmers but not "recommended" for prospective unix or linux
> programmers.
The book claims to be "designed for all C programmers".
<nonsense snipped>
Phil Carmody
> Seebs <usenet...@seebs.net> writes:
>> On 2010-04-06, Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>> And then there are some of the most
>>> convoluted input loops I've seem since I stopped marking first year
>>> students' work[1].
>>
>>> [1] For example:
>>
>>> char ch;
>>> /* snip */
>>> while(!feof(in)) {
>>> ch = getc(in);
>>> if(!feof(in)) putc(ch, out);
>>> }
>>
>> This one is, strictly speaking, at least correct. Mostly.
>
> Does your use of "Mostly" refer to the fact that the code will go into
> an infinite loop on an input error?
I thought it referred mostly to /Aliens/. Mostly.
Richard Heathfield
<snip>
> Based on finding 6 errors and inflating them to only 20,
> you've made an absurd generalization.
Random quote from CTCR 2nd edition. This one is from p154:
"The argc parameter holds the number of arguments on the command line
and is an integer. It is always at least 1 because the name of the
program qualifies as the first argument."
This is wrong. It is perfectly legal for argc to be 0 and argv[argc] to
be a null pointer, and it's not even terribly difficult to do.
Since we're on that page anyway, here are two more errors, this time to
do with argv:
"The argv parameter is a pointer to an array of character pointers. Each
element in this array points to a command line argument."
Firstly, it's actually a pointer to *the first element of* an array of
character pointers. Terminology is especially important in a tutorial!
Secondly, argv[argc] is an element in the array which does not point to
a command line argument.
<snip>
Phil Carmody
>>> On Apr 5, 2:55 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
>>> wrote:
>>>> 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.
>>
>> binary operator.
>
>
n869:
[#1] The first operand of the . operator shall have a
qualified or unqualified structure or union type, and the
second operand shall name a member of that type.
...
> The overriding consideration, IMHO, is that the C standard calls
> it a postfix operator.
That has 2 explicitly-yclept operands.
spinoza1111
> On 2010-04-06, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > spinoza1111 wrote:
> >> I shall rejoin this discussion prematurely
> > Prediction fulfilled. (See Message-ID:
>
> I think that's shooting fish in a barrel territory.
>
> > I see no attacks on Malcolm's credibility in this thread. I do see some
> > fairly hefty attacks on his argument, but that's only because his
> > argument is broken.
>
> And also a bit of concern about why he would jump in and make silly
> claims ("it's a tutorial, not a reference" -- HUH?!).
>
> >> Peter, the issue here isn't Schildt's book. It is "C: the Complete
> >> Nonsense", not "C: the Complete Reference".
> > The one is a commentary on the other. Therefore, both are relevant to
> > the thread.
>
> Yes. The commentary can only be evaluated in terms of the thing commented
> on.
>
> > If on specific errata he is right, it adds up to a proper critique,
> > unless there are a significant number of specific errata that he got
> > wrong. This you have failed to demonstrate.
>
> I think there's certainly a meaningful sense in which it's not a
> "proper critique"; if I went to someone for a professional-quality
> book review, and got back C:TCN, I'd be upset.
Very good. We're making progress. OK, you have write access to the
post. I will drop the matter if you replace it by a blank post, or
something saying "withdrawn". You do not need to apologize therein to
Herb, you do not need to apologize for the damage you've done to me,
and you do not need to notify me of your action.
>
> But as things posted on the internet for free roughly 15 years ago go,
> it's not bad.
I do not accept arguments of this form. "My classmates are stupid
therefore I am smart" is not a valid inference. Furthermore, viral
replication of the claims, scattered over many different sites, is the
problem.
If you would just blank the site, I can then go into wikipedia as an
anonymous ip address and quite properly remove the section of the
article on Schildt that continues to damage his reputation.
>
> >> I will take responsibility for
> >> repairing wikipedia
> > No wonder it has such a bad reputation, if people like you are
> > "repairing" it. But I thought you'd been banned from "repairing" Wikipedia?
>
> Well, yes. The purpose of this whole thing seems to be that the Wikipedia
> admins chose to accept the C:TCN page as sufficient evidence that the
> "controversy" section deserved to be there. Thus, if Nilges can get enough
> people to argue that C:TCN isn't a very good critique... nothing happens.
It is now a Reception section, but overgeneralizes the canard to apply
to all of Schildt's output, not just CTCR. If the page is blanked,
since the Schildt page isn't locked, this will justify even an
anonymous editor such as myself (who will possibly recognized as
someone who's "blocked" based on my self-defense over Kant changes in
2006) from removing an UNSOURCED "Reception" section, under the rules
of "biographies of living persons".
This will lay this matter to rest and demonstrate that the Internet
can arrive at a conclusion that is fair to all.
>
> Because the underlying point isn't anything to do with C:TCN. It's that
> the page is an *example* of the general category of "reputable C experts who
> have served on the committee pan Schildt's work". Clive's commentary would
Clive is a troll who was galvanized by your post.
> do just as well. For that matter, even if C:TCN went away, it wouldn't
> change the fact that I'm quite clearly on the record as stating that the
> book is junk that I would never inflict on someone trying to learn C.
>
> If people really care, hey, I can always do a proper critique. I've got
> another ~15 years of writing and programming experience to draw on since
> the days when I wrote C:TCN. That said...
>
> If I were to write such a page today, based on the 4th edition, it would have
> fewer nitpicking errors, but I could do a much better job of explaining in
> detail, and presenting effectively, the case that the remaining errors both
> conceptual and technical are serious enough to utterly dispel any notion
> that the book ought to be used to learn from. I know a lot more about
> writing, and about how to teach people about computers, and about C, than I
> did back in ~1995 or so. My impressions of Schildt's work have not changed
> for the better.
You can do that, of course. However, to do an acceptable job, you need
to provide all of what you think are errors, and you have to be
prepared to have to defend your document. It appears to me that you do
not have enough academic experience in this type of interchange to
know how time-consuming this would be for you. I think it would be
better for you to return to school and learn the trade you profess.
Just blank the page, Peter, and this matter will disappear and be
forgotten.
>
> -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
Phil Carmody
...
I've previously been utterly content that I have no copies of
any edition of this book, for obvious reasons. However, you
having turned it into a game have reversed that, and I have a
nasty feeling if I see one on the cheap, I'll not be able to
resist...
spinoza1111
> spinoza1111 wrote:
>
> <snip>
>
> > Based on finding 6 errors and inflating them to only 20,
> > you've made an absurd generalization.
>
> Random quote from CTCR 2nd edition. This one is from p154:
>
> "The argc parameter holds the number of arguments on the command line
> and is an integer. It is always at least 1 because the name of the
> program qualifies as the first argument."
>
> This is wrong. It is perfectly legal for argc to be 0 and argv[argc] to
> be a null pointer, and it's not even terribly difficult to do.
Prints one with a command line with no arguments BEYOND the name of
the command:
#include "stdio.h"
int main(int argc, char *argv)
{
printf("%d\n", argc);
}
Prints "0 0":
#include "stdio.h"
int main(int argc, char *argv)
{
argc = 0;
argv = 0;
printf("%d %d\n", argc, argv);
}
Sure, it's easy (especially, apparently, for you and Peter) to mess
up, but working programmers as opposed to corporate drones and casual
workers with too much time on their hands need to know the normed
case, which is that argc is going to be one when there are no
arguments other than the name of the command. This is because C, as
elsewhere, is a bit messed up in counting arguments, and includes the
name of the module. This is in turn because C was designed for
programming a command line interface which is pretty much out of date.
K & R were showing off their knowledge that zero is a number, and
admittedly, IBM in the 1960s and in Fortran had obscured this fact by
one-origin indexing. This was refreshing and enlightening at the time
but it's been FORTY YEARS since then, and today thinking of computing
as a series of commands on a Teletype is an absurd model.
You are as usual maliciously lying and will face the man in the grey
wig if you keep it up.
>
> Since we're on that page anyway, here are two more errors, this time to
> do with argv:
>
> "The argv parameter is a pointer to an array of character pointers. Each
> element in this array points to a command line argument."
>
> Firstly, it's actually a pointer to *the first element of* an array of
> character pointers. Terminology is especially important in a tutorial!
Utterly absurd. Will you PLEASE just crawl back to whatever rock you
crawled out of? In ordinary metalanguage, the first position
represents the array as a whole.
> Secondly, argv[argc] is an element in the array which does not point to
> a command line argument.
Oh gee you're so smart, aren't you. Heathfield, stop grandstanding;
you look like a fool.
spinoza1111
wrote:
> Keith Thompson <ks...@mib.org> writes:
> > Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> [SNIP - countering PS's C:TCN]
>
> > 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.
>
> When I first learnt C, it was being called the "free store" or
Incorrect use of the participle "learnt" for the past tense of to
learn.
> something so similar my memory cannot distinguish it. Given that
> the 'heap' isn't structurally or algorithmically a 'heap', I always
> wondered why a less baggage-laden term wasn't more popular.
Actually, the primitive structure Herb was talking about is indeed a
"heap" in an abstract sense and in contrast to the stack. The stack
contains small and fixed length values. When a value (a struct or
array) doesn't fit, we use an address in a free store. OO practice was
based on this.
I first saw the usage of "heap" in Saul Rosen's 1968 collection of
papers on early software. A computer scientist who actually programs
narrates what she's doing in ways that may seem to uneducated mere
programmers as incorrect, but I prefer her definitions.
Scientists know what a word means. Little technicians rely on
"terminology".
Richard Heathfield
<snip>
> If you would just blank the site, I can then go into wikipedia as an
> anonymous ip address and quite properly remove the section of the
> article on Schildt that continues to damage his reputation.
That's the big problem with Wikipedia - any bozo can edit it, and many
bozos do. Fortunately, Seebs isn't about to "blank the site" any time soon.
Random quote from CTCR2e. This one's from pages 510-511.
Example
This program uses the system time to randomly initialize the rand()
function by using srand():
#include "stdio.h"
#include "stdlib.h"
#include "time.h"
/* Seed rand with the system time
and display the first 10 numbers.
*/
void main(void)
{
int i, stime;
long ltime;
/* get the current calendar time */
ltime = time(NULL);
stime = (unsigned) ltime/2;
srand(stime);
for(i=0; i<10; i++) printf("%d ", rand());
}
Here are the problems I can see at a quick glance:
1) incorrect claim about behaviour of program;
2) unwise use of quotes rather than angle-brackets for standard headers;
3) using the wrong return type for main;
4) using a long int instead of a time_t to accept the return value from
time();
5) assigning an unsigned int value to an int object;
6) passing an int value to srand(), which expects an unsigned int;
7) failing to terminate a text stream;
8) failing to return a value from main.
When I tried to compile this code, Borland C rejected it (and refused to
produce an object file or an executable image) on the grounds that the
return type of main was wrong. When I told it not to be quite so fussy,
I got the following results on three successive runs of the program:
Run 1: 13044 19141 284 32137 28152 23678 16250 10654 12234 27596
Run 2: 13044 19141 284 32137 28152 23678 16250 10654 12234 27596
Run 3: 13044 19141 284 32137 28152 23678 16250 10654 12234 27596
It doesn't take a genius to work out why.
spinoza1111
>
> > spinoza1111 wrote:
> >> I shall rejoin this discussion prematurely
> > Prediction fulfilled. (See Message-ID:
>
> I think that's shooting fish in a barrel territory.
>
> > I see no attacks on Malcolm's credibility in this thread. I do see some
> > fairly hefty attacks on his argument, but that's only because his
> > argument is broken.
>
> And also a bit of concern about why he would jump in and make silly
> claims ("it's a tutorial, not a reference" -- HUH?!).
Don't start in on Malcolm, please. You've done enough damage.
>
> >> Peter, the issue here isn't Schildt's book. It is "C: the Complete
> >> Nonsense", not "C: the Complete Reference".
> > The one is a commentary on the other. Therefore, both are relevant to
> > the thread.
>
> Yes. The commentary can only be evaluated in terms of the thing commented
> on.
Wrong. The commentary is absurd.
>
> > If on specific errata he is right, it adds up to a proper critique,
> > unless there are a significant number of specific errata that he got
> > wrong. This you have failed to demonstrate.
>
> I think there's certainly a meaningful sense in which it's not a
> "proper critique"; if I went to someone for a professional-quality
> book review, and got back C:TCN, I'd be upset.
>
> But as things posted on the internet for free roughly 15 years ago go,
> it's not bad.
>
> >> I will take responsibility for
> >> repairing wikipedia
> > No wonder it has such a bad reputation, if people like you are
> > "repairing" it. But I thought you'd been banned from "repairing" Wikipedia?
>
> Well, yes. The purpose of this whole thing seems to be that the Wikipedia
> admins chose to accept the C:TCN page as sufficient evidence that the
> "controversy" section deserved to be there. Thus, if Nilges can get enough
> people to argue that C:TCN isn't a very good critique... nothing happens.
>
> Because the underlying point isn't anything to do with C:TCN. It's that
It has everything to do with CTCN.
> the page is an *example* of the general category of "reputable C experts who
You are not a reputable C expert.
You have not published on C (please respond if you can with articles
on C only that I have missed).
You have shown yourself to be an incompetent C coder who fails to
write structured code and makes newbie errors in the last three
months.
Your only known confederates are Clive Feather, a nasty piece of work,
and Richard Heathfield, a nasty piece of work.
You have zero experience in the use of C outside of unix.
> have served on the committee pan Schildt's work". Clive's commentary would
You paid your way in. I believe you did so as resume padding. You have
admitted padding your online resume to make it appear that you have
worked for Apple Computer since 1987 and are a venture capitalist for
them.
> do just as well. For that matter, even if C:TCN went away, it wouldn't
> change the fact that I'm quite clearly on the record as stating that the
> book is junk that I would never inflict on someone trying to learn C.
Yes, but nobody would care.
>
> If people really care, hey, I can always do a proper critique. I've got
> another ~15 years of writing and programming experience to draw on since
> the days when I wrote C:TCN. That said...
>
> If I were to write such a page today, based on the 4th edition, it would have
> fewer nitpicking errors, but I could do a much better job of explaining in
> detail, and presenting effectively, the case that the remaining errors both
> conceptual and technical are serious enough to utterly dispel any notion
> that the book ought to be used to learn from. I know a lot more about
> writing, and about how to teach people about computers, and about C, than I
> did back in ~1995 or so. My impressions of Schildt's work have not changed
> for the better.
Nobody would trust you. I think Ben should do this. And I believe he
would discover that he needs to learn more about Microsoft to do a job
according to his high standards, and would give up halfway through.
>
> -s
> --
Richard Heathfield
> On Apr 6, 4:28 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> spinoza1111 wrote:
>>
>> <snip>
>>
>>> Based on finding 6 errors and inflating them to only 20,
>>> you've made an absurd generalization.
>> Random quote from CTCR 2nd edition. This one is from p154:
>>
>> "The argc parameter holds the number of arguments on the command line
>> and is an integer. It is always at least 1 because the name of the
>> program qualifies as the first argument."
>>
>> This is wrong. It is perfectly legal for argc to be 0 and argv[argc] to
>> be a null pointer, and it's not even terribly difficult to do.
>
> Prints one with a command line with no arguments BEYOND the name of
> the command:
Huh? That makes no sense at all.
>
> #include "stdio.h"
> int main(int argc, char *argv)
> {
> printf("%d\n", argc);
> }
>
> Prints "0 0":
No, it prints the value of argc. So, if there are no arguments, it will
print 0, not 0 0.
>
> #include "stdio.h"
> int main(int argc, char *argv)
> {
> argc = 0;
> argv = 0;
> printf("%d %d\n", argc, argv);
> }
>
> Sure, it's easy (especially, apparently, for you and Peter) to mess
> up,
You misunderstand. It's Schildt who messed up, by making an incorrect
claim that argc is always >= 1.
<nonsense snipped>
Let's play the random game again. P298 of CTCR2e:
int fflush(FILE *stream);
Description
If stream is associated with a file open for writing, a call to fflush()
physically writes to the file the contents of the output buffer. If
stream points to an input file, the contents of the input buffer are
cleared. In either case, the file remains open.
Problems: firstly, the fflush() function doesn't physically write
anything. What it does is to deliver any unwritten data for that stream
to the host environment. It is the host environment that physically
writes the data... at a time of its choosing! There is no guarantee
that, on return from fflush(), the data have been written, even if no
error occurred. Secondly, the behaviour of fflush() when passed a FILE *
that is associated with an "input file" is undefined.
Walter Banks
spinoza1111 wrote:
> , you'd know that the author is
> not in charge of the cover material.
The text content of the cover is part of the galleys sent
to the author for fact checking and approval.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Colonel Harlan Sanders
<spino...@yahoo.com> wrote:
>On Apr 6, 3:26 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> I think there's certainly a meaningful sense in which it's not a
>> "proper critique"; if I went to someone for a professional-quality
>> book review, and got back C:TCN, I'd be upset.
>
>Very good. We're making progress. OK, you have write access to the
>post. I will drop the matter if you replace it by a blank post, or
>something saying "withdrawn". You do not need to apologize therein to
>Herb, you do not need to apologize for the damage you've done to me,
>and you do not need to notify me of your action.
>>
>> But as things posted on the internet for free roughly 15 years ago go,
>> it's not bad.
>
>I do not accept arguments of this form. "My classmates are stupid
>therefore I am smart" is not a valid inference. Furthermore, viral
>replication of the claims, scattered over many different sites, is the
>problem.
I think he's apologising for not demolishing CTCR more thoroughly. Not
for doing so incorrectly.
-- You seem to really believe that Seebs wrote a web page 15 years
ago, then used his Jedi power to hypnotise the world into believing
it. And that you can break this spell by bullying, threatening and
screaming at him to delete the page.
>If you would just blank the site, I can then go into wikipedia as an
>anonymous ip address and quite properly remove the section of the
>article on Schildt that continues to damage his reputation.
And it will be reverted a few minutes later, as the last 500 times you
tried to do this.
Because, even if you did manage to get rid of Seebs' page (which I'd
lay loooong odds against), the statements you are so het up about are
supported by other sources:
from http://en.wikipedia.org/wiki/Herbert_Schildt
>Reception
>
>Schildt's books have a reputation for being written in
>a clear style that is very easy to understand.[1]
>However, their technical accuracy has been criticized.
>Peter Seebach, a former voting member of ISO C
>committee and moderator of the Usenet group
>comp.lang.c.moderated, alleges that Schildt's C: The
>Complete Reference contains code with beginner's
>mistakes and statements suggesting the wrong idea.[1]
>Schildt's The Annotated ANSI C Standard was similarly
>criticized by Clive Feather, who is also an ISO C
>committee member, and by Steve Summit, author of the C
>FAQ.[2][3]
So before you can think about censoring this section you would have to
target Feather and Summit and get them to amend their critiques.
Ain't going to happen. Feather made his opinions clear some months ago
when you started this insane crusade.
By the way, the current threads you are generating here are producing
more support to the "Schildt is crap" side of the argument.
If anyone feels inclined to compile relevant posts into a webpage
these can be cited more readily than Usenet posts and can be added to
the References section of the wiki page.
By the way,
On Sun, 4 Apr 2010 05:05:21 -0700 (PDT), spinoza1111
<spino...@yahoo.com> wrote:
>I will stop posting and reading until Sunday 11 April China time.
Another bare-faced lie, a promise broken less than two days later.
You will go ballistic if anyone questions your word, yet over and over
you demonstrate it is worth nothing.
James Harris
> On Apr 6, 3:26 pm, Seebs <usenet-nos...@seebs.net> wrote:
...
> > I think there's certainly a meaningful sense in which it's not a
> > "proper critique"; if I went to someone for a professional-quality
> > book review, and got back C:TCN, I'd be upset.
>
> Very good. We're making progress. OK, you have write access to the
> post. I will drop the matter if you replace it by a blank post, or
> something saying "withdrawn". You do not need to apologize therein to
> Herb, you do not need to apologize for the damage you've done to me,
> and you do not need to notify me of your action.
...
> If you would just blank the site, I can then go into wikipedia as an
> anonymous ip address and quite properly remove the section of the
> article on Schildt that continues to damage his reputation.
Weren't you "banned" from Wikipedia for making inappropriate edits
including under anonymous IP addresses?
Please don't even consider removing what you call "the section of the
article on Schildt that continues to damage his reputation." Apart
from Peter Seebach's comments the "section" refers to two other
sources of criticism. Even if Peter does what you request - and I hope
he does not - that would be no mandate for you to remove references to
other criticism.
...
> > If I were to write such a page today, based on the 4th edition, it would have
> > fewer nitpicking errors, but I could do a much better job of explaining in
> > detail, and presenting effectively, the case that the remaining errors both
> > conceptual and technical are serious enough to utterly dispel any notion
> > that the book ought to be used to learn from. I know a lot more about
> > writing, and about how to teach people about computers, and about C, than I
> > did back in ~1995 or so. My impressions of Schildt's work have not changed
> > for the better.
>
> You can do that, of course. However, to do an acceptable job, you need
> to provide all of what you think are errors, and you have to be
> prepared to have to defend your document. It appears to me that you do
> not have enough academic experience in this type of interchange to
> know how time-consuming this would be for you. I think it would be
> better for you to return to school and learn the trade you profess.
An update to Peter's criticism would be beneficial. As he himself
recognises there are ways it could be improved such as by removing
nitpicking errors. Time has moved on but for a 15-year old document
it's not bad.
If you are an academic, Edward, you should recognise the value of
assertion and criticism. The presence of both serves to produce a
better-informed readership. Notwithstanding my view that the critical
page of Peter's would benefit from an update, ISTM that the Wikipedia
article is balanced as it stands. I don't understand what's motivating
your desire to change it.
James
spinoza1111
> On Apr 5, 5:48 am, Keith Thompson <ks...@mib.org> wrote:
... snip snip snippy snip: you nasty little clerks are right as you
often are, on something trivial: I need to snippety snip more ...
> However, a literate person knows how to disambiguate "is", as do
> literate OO programmers, who use "is-a" to show subset in inheritance
> as opposed to "has-a" to show reference to an object, and "==" in C
> Sharp in Java to show identity.
Error: change in to or.
Snip snip snippety snip
I need to get wise, and I need to get hip,
And follow the trivial rules
That have lighted fools
The way to dusty death
Sorta like Macbeth.
You know the old play.
Glamis, then Cawdor, then the buttered Scone:
But what's little noticed and lesser known,
Is Macbeth's foolish logic...he's brainsick.
I mean, those bitches on the heath-field
Crones that call to Richard in his lonely room,
Prophesied he should be Cawdor, and he wuz:
So what does the kilted Jocko do?
He kilts Duncan like a scuz!
This sort of subhumanity
We see here, and it's a tragedy:
For 6 errata don't make your case
Any more than you prove jackshit when a mess you makes
Out of argc
And also argv.
Macbeth wanted the throne, to sit his arse upon the throne,
Before he met Heathfield's grannies and aunties in th' gloam.
Likewise Seebach plucks at prophesies and dreams
To pretend he's competent, and at night he screams.
spinoza1111
> spinoza1111 wrote:
> > , you'd know that the author is
> > not in charge of the cover material.
>
> The text content of the cover is part of the galleys sent
> to the author for fact checking and approval.
That is correct: Apress did that for me. However, in many situations,
it's too much "time" (especially in a larger company than Apress, like
McGraw Hill) to make the change on deadline.
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
Richard Heathfield
As usual, you are wrong. Peter Seebach wrote the recursion and C99
chapters of "C Unleashed". If you would care to check the errata for
those chapters, you will find a total of seven mistakes by Seebs. Please
feel free to use these very serious errors as ammunition in your
campaign of personal destruction.
<nonsense snipped>
Oh yes, it's time to play the random game again.
CTCR2e, Herbert Schildt, p152:
For example, consider the function print_upper(), which prints its
string argument in uppercase:
#include "stdio.h"
#include "ctype.h"
void print_upper(char *string);
void main(void)
{
char s[80];
gets(s);
print_upper(s);
}
/* Print a string in uppercase. */
void print_upper(char *string)
{
register int t;
for(t=0; string[t]; ++t) {
string[t] = toupper(string[t]);
putchar(string[t]);
}
}
After my usual plea with the compiler not to be too fussy about void
main, I fed the program a file (redirected to stdin) that consisted
entirely of upper case characters, and the program responded by
crashing, without producing any output.
James Harris
> On Apr 6, 3:26 pm, Seebs <usenet-nos...@seebs.net> wrote:
...
> > the page is an *example* of the general category of "reputable C experts who
>
> You are not a reputable C expert.
>
> You have not published on C (please respond if you can with articles
> on C only that I have missed).
>
> You have shown yourself to be an incompetent C coder who fails to
> write structured code and makes newbie errors in the last three
> months.
>
> Your only known confederates are Clive Feather, a nasty piece of work,
> and Richard Heathfield, a nasty piece of work.
"A nasty piece of work"! Is this one of those irregular definitions
such as
"I am forthright"
"You are abusive"
"He is a nasty piece of work"
Or is it a term which you use for those who disagree with you.
Perhaps: for those who disagree with you and for whom you are running
out of arguments to counter.
I've noticed that Richard has been making comments on the issues with
pieces of code in an edition of the book. And thanks to you bringing
the matter up in this thread some minor and some fairly serious
criticisms have been levelled at Schildt's work. The main problem with
your argument, ISTM, is that you haven't made an effective defence of
his code.
In fact you seem to focus on personal attacks on others. By doing so I
would say that you are showing yourself to be "a nasty piece of
work." (My definition, this time.)
> You have zero experience in the use of C outside of unix.
Are you unable to see that, even if true, this is irrelevant? If
something is misleading it is misleading no matter who says so.
Continually attacking or challenging where people come from is
immaterial if the points they are maing are valid.
If the points are wrong then say so, and say why. To waffle on about
who people knew or what their background is is irrelevant when the
issues are plain, unambiguous and open to discussion which is the case
here.
James
spinoza1111
> On 6 Apr, 09:43, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > On Apr 6, 3:26 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> ...
>
> > > I think there's certainly a meaningful sense in which it's not a
> > > "proper critique"; if I went to someone for a professional-quality
> > > book review, and got back C:TCN, I'd be upset.
>
> > Very good. We're making progress. OK, you have write access to the
> > post. I will drop the matter if you replace it by a blank post, or
> > something saying "withdrawn". You do not need to apologize therein to
> > Herb, you do not need to apologize for the damage you've done to me,
> > and you do not need to notify me of your action.
>
> ...
>
> > If you would just blank the site, I can then go into wikipedia as an
> > anonymous ip address and quite properly remove the section of the
> > article on Schildt that continues to damage his reputation.
>
> Weren't you "banned" from Wikipedia for making inappropriate edits
> including under anonymous IP addresses?
That's correct. And you can find a full discussion of this between
myself and someone who at least appears to be Jimmy Wales, wikipedia's
founder, at http://spinoza1111.wordpress.com/2010/01/06/wikipedias-racist-bullying-redux/.
The fact is that in 2006, wikipedia drove out educated contributors
and replaced them by convenience store clerk types who applied rules
without subject matter knowledge. This is well known and is confirmed
by many former contributors.
In my case I was with the encouragement of the informal moderator of
changes to the Kant page (a uni prof) making contributions, but my
experience in teaching philosophy in various capacities since 1973 is
that to TEACH philosophy you must DO philosophy. This bothered
somebody called amerindianarts and he started edit warring my changes.
I was like, kemosabe, up yours because I don't suffer fools gladly.
However, today's techno-peasants (cf. Jaron Lanier, You Are Not a
Gadget) are taught to grin and shuffle, so I was tagged as a bad
nigra.
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.
It is also said that I was "banned" from a local placeblog. What
happened was that (1) I was made a moderator by the big cheese. (2)
Other moderators, disturbed by my literacy and the fact that based on
original graphics I posted, I became "artist of the month" with a one
man show in a local gallery, started disrupting "my" group. (3) I
invited them to perform an aerial reproductive maneuver. (4) My
privileges were reduced by the big cheese. (5) I left since this was a
waste of time.
>
> Please don't even consider removing what you call "the section of the
> article on Schildt that continues to damage his reputation." Apart
> from Peter Seebach's comments the "section" refers to two other
> sources of criticism. Even if Peter does what you request - and I hope
> he does not - that would be no mandate for you to remove references to
> other criticism.
Excuse me, don't bore me with things I already know. The fact is that
before January of last year, the Schildt article, which was created to
trash the guy, was in serious violation of Biographies of Living
Persons, wikipedia's own policy. I changed it as a "blocked" user and
that change has been effective ever since. If Peter simply blanks CTCN
I can go back and get the Reception section changed.
The Reception section mischaracterises Seebach as "a former voting
member of ISO C committee and moderator of the Usenet group
comp.lang.c.moderated". The fact is, as he has himself confirmed, he
paid his way onto the ISO committee and as a moderator, he does no
work, allowing all posts through. But if we can get CTCN removed from
the Internet, this will make our case for the removal of the Reception
section.
It's not really appropriate that Schildt has a wikipedia biography in
the first place, since being a hard working computer author and
musician is not by itself significant enough. Dan Appleman has
published extensively on programming, is one of the nicest guys I'd
care to know, was slashdotted, and is currently a technology columnist
for the San Francisco Chronicle, but does not merit a wikipedia
biography. The Schildt biography was created, and sourced solely on
Seebach's attack on CTCR (and Feather's attack on C: the Annotated
Standard, a copycat crime), in order to pad the anti-Schildt "case".
Nobody's going to create a wikipedia article about me despite the fact
that I'm a hard working author and teacher and a good looking, sexy
guy, unless they wish to immortalize "Nilgewater" as a term of art;
but this was tried, I complained, and the entry disappeared into thin
air.
Private people who work hard, whether Schildt, Kathy Sierra, or Kim
Pring (a Miss Utah lampooned in Hustler) have a right under the UN
Declaration of Human Rights and the Ninth Amendment to the US
Constitution insofar as the latter applies to PRIVACY. As it is, even
defending them as I do (I got the Sierra article repaired as well as a
"blocked" user) can cause them further anxiety. That is why I am
asking Peter Seebach to be a man for a change, and blank CTCN. This
matter will end.
>
> ...
>
> > > If I were to write such a page today, based on the 4th edition, it would have
> > > fewer nitpicking errors, but I could do a much better job of explaining in
> > > detail, and presenting effectively, the case that the remaining errors both
> > > conceptual and technical are serious enough to utterly dispel any notion
> > > that the book ought to be used to learn from. I know a lot more about
> > > writing, and about how to teach people about computers, and about C, than I
> > > did back in ~1995 or so. My impressions of Schildt's work have not changed
> > > for the better.
>
> > You can do that, of course. However, to do an acceptable job, you need
> > to provide all of what you think are errors, and you have to be
> > prepared to have to defend your document. It appears to me that you do
> > not have enough academic experience in this type of interchange to
> > know how time-consuming this would be for you. I think it would be
> > better for you to return to school and learn the trade you profess.
>
> An update to Peter's criticism would be beneficial. As he himself
> recognises there are ways it could be improved such as by removing
> nitpicking errors. Time has moved on but for a 15-year old document
> it's not bad.
>
> If you are an academic, Edward, you should recognise the value of
> assertion and criticism.
I am only an adjunct and free market academic. However, I have I think
a better sense of what "criticism" really is, based on teaching
logic.
It isn't inferring from finding 6 errata to a global charge that you
know will be replicated and amplified on the internet in the fallacy
of composition.
> The presence of both serves to produce a
> better-informed readership. Notwithstanding my view that the critical
> page of Peter's would benefit from an update, ISTM that the Wikipedia
> article is balanced as it stands. I don't understand what's motivating
> your desire to change it.
Such a Reception section could be made of most computer authors. Many
C programmers hate K & R. Shouldn't we give them a section in the
article on Kernighan? A coworker laughed at the title of The Art of
Computer Programming, since, he said, it's not an art. Shouldn't
ignorant people have a section in the Knuth article?
OF COURSE NOT, because Wikipedia's own Biographies of Living Persons
policy forbids gratuitous assaults on both people who are (in the
distinction made by the US Supreme Court in the case of Flynt v
Robertson) "public figures" and "private figures", with a higher, not
a lesser, standard for private figures.
The Wyoming lawyer Gerry Spence in fact lost a case in which he
defended a Utah beauty queen who was lampooned as giving blow jobs in
Hustler. I feel, however, his reasoning in this case was sound: it was
that private people who are for a temporary and special reason in the
public eye do not thereby become true public figures. A beauty queen
looks better in a bikini than I do as a computer author, but we're
both essentially private figures who for that reason deserve a higher
standard of care.
This is because mere employability is more important to most private
individuals, and these gratuitous "mean kids" attacks on Kim Pring,
Kathy Sierra, et al. harm their standing in their community and that
of their family members.
>
> James
Richard Harnden
> [...] The fact is, as he [Seebs] has himself confirmed, he
> paid his way onto the ISO committee [...]
So did Schildt. So what?
Richard Heathfield
<nonsense snipped>
> I was like, kemosabe, up yours because I don't suffer fools gladly.
That must make it very difficult to live with yourself.
<nonsense snipped>
>
> It isn't inferring from finding 6 errata to a global charge that you
> know will be replicated and amplified on the internet in the fallacy
> of composition.
Let's play the random game again.
Schildt's CTCR2e, p138. Note that the opening comment is Schildt's, not
mine!
/* Display powers of the numbers 1 through 10.
Note: even though this is a correct program,
some compilers will issue a warning message
concerning the argument to the functions
table() and show(). If this happens, just
ignore it.
*/
#include "stdio.h"
#include "stdlib.h"
int pwr(int a, int b);
void table(int p[4][10]);
void show(int p[4][10]);
void main(void)
{
int *p;
p = malloc(40*sizeof(int));
if(!p) {
printf("memory request failed\n");
exit(1);
}
/* here, p is simply a pointer */
table(p);
show(p);
}
/* Build the table of powers. */
void table(int p[4][10]); /* now the compiler has an array
to work with */
{
register int i,j;
for(j=1; j<11; j++)
for(i=1; i<5; i++) p[i][j] = pwr(j, i);
}
/* Display the table of integer powers. */
void show(int p[4][10]) /* now the compiler has an array
to work with */
{
register int i,j;
printf("%10s %10s %10s %10s\n",
"N", "N^2", "N^3", "N^4");
for(j=1; j<11; j++) {
for(i=1; i<5; i++) printf("%10d ", p[i][j]);
printf("\n");
}
}
/* Raise an integer to the specified power. */
pwr(int a, int b)
{
register int t=1;
for(; b; b--) t = t*a;
return t;
}
Okay, let's take it from the top:
1) the comment is wrong in claiming that the program is correct;
2) the comment contains unwise advice to ignore a useful warning;
3) the standard headers are unwisely enclosed in quotation marks
rather than angle-brackets;
4) the return type of main is wrong;
5) the program passes a non-portable value to exit();
6) the program passes an int * to a function expecting int p[4][10]
(this problem occurs twice on two consecutive lines);
7) a function takes a parameter of type int [4][10] (i.e. but
then attempts to access several elements that don't exist:
[0][10], [1][10], [2][10], [3][10], and [4][0] through [4][10];
8) another function does precisely the same thing.
I decided *not* to point out two other issues, one of them a matter of
robustness and the other having regard to efficiency, on the grounds
that this is supposed to be tutorial code for beginners - i.e. I
recognise the validity of the "one mountain at a time" technique.
<nonsense snipped>
Richard Heathfield
So did every member of the ISO C Committee, as far as I am aware. It's a
bit like getting on the train - you're supposed to have a ticket first.
> So what?
Indeed.
Richard Heathfield
<snip>
> I've previously been utterly content that I have no copies of
> any edition of this book, for obvious reasons. However, you
> having turned it into a game have reversed that, and I have a
> nasty feeling if I see one on the cheap, I'll not be able to
> resist...
Oh, I'm sorry about that. But we have yet to turn it into a *drinking
game*, as Seebs originally suggested.
Let's play the game again:
Schildt's CTCR2e, p502:
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.
I find it fascinating that I haven't yet had to search through the book
looking for errors. I just open it at random, and bang! there's another
one. I do have to do a /little/ work, though, because I'm trying to
avoid posting any for which either Schildt has already posted an
acknowledgement and correction or Seebs has already posted a critique.
Schildt's Web site does contain an Errata section, but it has no entries
for CTCR, so that's that - but I do have to keep checking Seebs's site.
<sigh>
Those of you who have started looking forward in macabre glee to my next
random Schildt bug will have to wait a few days, however, as my current
schedule makes it difficult to get to Usenet except at the weekends (for
a mildly bizarre definition of "weekends"). And no, I'm not planning on
taking CTCR on the train with me...
Malcolm McLean
> On 2010-04-06, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > I see no attacks on Malcolm's credibility in this thread. I do see some
> > fairly hefty attacks on his argument, but that's only because his
> > argument is broken.
>
> And also a bit of concern about why he would jump in and make silly
> claims ("it's a tutorial, not a reference" -- HUH?!).
>
gain. I think that "the book tries to be both a tutorial and a
reference" might be a valid criticism. But you don't actually make
that criticism.
>
> Yes. The commentary can only be evaluated in terms of the thing commented
> on.
>
happened to misquote Schildt there would be no way of knowing about it
without going to the original, you can tell whether a commentary is
trying to be balanced or not, or whether some of the points it makes
are fair, without actually seeing the original. Which is what I've
done.
>
> I think there's certainly a meaningful sense in which it's not a
> "proper critique"; if I went to someone for a professional-quality
> book review, and got back C:TCN, I'd be upset.
>
sneering tone, so "C: the complete nonsense" is no good as an errata
page. However it's not a review. Slamming reviews are acceptable, but
they can't consist entirely or mainly of nitpicks, especially when the
book is over 700 pages long. When half of the nitpicks aren't even
right, the credibiility of the critique goes down even further.
However "C: the complete nonsense is a bad webpage" isn't the
same as "C: the complete reference is a good book". It is possible to
make a bad criticism of a bad book.
Walter Banks
Richard Heathfield wrote:
> Richard Harnden wrote:
> > On 06/04/2010 11:43, spinoza1111 wrote:
> >> [...] The fact is, as he [Seebs] has himself confirmed, he
> >> paid his way onto the ISO committee [...]
> >
> > So did Schildt.
>
> So did every member of the ISO C Committee, as far as I am aware. It's a
> bit like getting on the train - you're supposed to have a ticket first.
>
> > So what?
>
> Indeed.
It is splitting hairs but any fees maybe paid are to national standards
groups who are responsible for sending representatives to ISO meetings.
Fees are not normally paid by individuals to ISO. In the US this is ANSI
which has a fee structure for individuals. In Canada the Canadian Stanadards
Association is our link to ISO.
Walter Banks
Walter Banks
spinoza1111 wrote:
> On Apr 6, 5:53 pm, Walter Banks <wal...@bytecraft.com> wrote:
> > spinoza1111 wrote:
> > > , you'd know that the author is
> > > not in charge of the cover material.
> >
> > The text content of the cover is part of the galleys sent
> > to the author for fact checking and approval.
>
> That is correct: Apress did that for me. However, in many situations,
> it's too much "time" (especially in a larger company than Apress, like
> McGraw Hill) to make the change on deadline.
The "bigger companies" it is not a question of time but due diligence.
The author signs off on the galleys before the book goes to press. The
actual press time is not scheduled until that point.
This is why Schildt not his publisher is ultimatly responsible for the
content.
w..
spinoza1111
wrote:
> On 6 Apr, 08:26, Seebs <usenet-nos...@seebs.net> wrote:> On 2010-04-06, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > > I see no attacks on Malcolm's credibility in this thread. I do see some
> > > fairly hefty attacks on his argument, but that's only because his
> > > argument is broken.
>
> > And also a bit of concern about why he would jump in and make silly
> > claims ("it's a tutorial, not a reference" -- HUH?!).
>
> I haven't actually read the book. However that's the impression I
> gain. I think that "the book tries to be both a tutorial and a
> reference" might be a valid criticism. But you don't actually make
> that criticism.
Yes, and for most readers, all editions but the fourth are
unavailable. Libraries deaccess old computer books and used book
dealers don't want them unless they are known classics on computer
science...not programming. This means that if Seebach doesn't at least
keep the page up to date, it is not a valid criticism and should not
be referenced in wikipedia.
>
> > Yes. The commentary can only be evaluated in terms of the thing commented
> > on.
>
> Whilst there are some things we cannot tell, for instance if you
> happened to misquote Schildt there would be no way of knowing about it
> without going to the original, you can tell whether a commentary is
...and as above the original is unavailable to most checkers...
> trying to be balanced or not, or whether some of the points it makes
> are fair, without actually seeing the original. Which is what I've
> done.
...as I have. Where Seebie seems to be right I have acknowledged it.
But there are only, as I have shown, six solid errata in CTCN. Not
enough to base his or anyone else's case.
>
> > I think there's certainly a meaningful sense in which it's not a
> > "proper critique"; if I went to someone for a professional-quality
> > book review, and got back C:TCN, I'd be upset.
>
> You said it. It's very unprofessional to make bug reports in a
I quite agree.
> sneering tone, so "C: the complete nonsense" is no good as an errata
Starting with its snarky title.
> page. However it's not a review. Slamming reviews are acceptable, but
> they can't consist entirely or mainly of nitpicks, especially when the
> book is over 700 pages long. When half of the nitpicks aren't even
> right, the credibiility of the critique goes down even further.
> However "C: the complete nonsense is a bad webpage" isn't the
> same as "C: the complete reference is a good book". It is possible to
> make a bad criticism of a bad book.
Quite so. In fact, Amazon contains thousands.
Peter: two distinguished people here, Dr. McClean and Navia, the
author of lcc as it exists today, have concurred in general with me.
Don't you think it's time to blank CTCN at a minimum?
spinoza1111
> Phil Carmody wrote:
>
> <snip>
>
> > I've previously been utterly content that I have no copies of
> > any edition of this book, for obvious reasons. However, you
> > having turned it into a game have reversed that, and I have a
> > nasty feeling if I see one on the cheap, I'll not be able to
> > resist...
>
> Oh, I'm sorry about that. But we have yet to turn it into a *drinking
> game*, as Seebs originally suggested.
>
> Let's play the game again:
>
> Schildt's CTCR2e, p502:
>
> 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.
Richard, this is a stupid game. Anyone's code snippets have any number
of preconditions, and no professional programmer cuts and pastes so
blindly. I realize that you're not a professional programmer, but
don't use your ignorance of your trade as an argument.
Furthermore, you're using an out of date edition.
For the last time, scumbag. Proving that your computer teachers were
mistaken about something, and proving that a computer author made
mistakes, does not make you competent or of service to others except
in a barbaric and fantasy logic. We have tools such as compiler
diagnostics for finding random errors. We expect from you
professionalism and decency, and you don't show it.
spinoza1111
<snipped>
This group has some very evil people in it, so here's a revised and
corrected copy of my Macbeth poem. Poetry can drive out evil spirits.
Snip snip snippety snip
I need to get wise, and I need to get hip,
And follow the trivial rules
That have lighted fools
The way to dusty death
Sorta like Macbeth.
You know the old play.
Glamis, then Cawdor, then the buttered Scone:
But what's little noticed and lesser known,
Is Macbeth's foolish logic...he's brainsick.
I mean, those bitches on the heath-field
Crones that call to Richard in his lonely room,
Prophesied that Macbeth should be Cawdor, and he wuz:
So what did the kilted Jocko do?
He kilted Duncan like a scuz!
This sort of subhumanity
We see here, and it's a tragedy:
For six errata do not make your case
Any more than you prove jackshit when a mess you makes
Out of argc
And also argv.
Macbeth wanted the throne, to sit his arse upon the Stone,
Before he met Heathfield's grannies and aunties in th' gloam.
Likewise Seebach plucks at prophecies and dreams
Seebs
*bamf*
> "I had been given the mission of creating a complete reference guide to
> the C programming language. Not just /any/ book, but the /complete/ book."
*snerk*
> Okay, this is from page 420 of the second edition of CTCR, not a page I
> recall seeing before.
Well! This is fortuitous.
The 2nd and 3rd edition are extremely similar in page numbering, and while
paging to it, I found my receipt.
I bought the 3rd edition on 1/22/96, specifically to write about it, so I
can now state that the page in question is just over 14 years old. 15 was
an estimate based on the book's copyright date.
It's now page 407, by the way.
> This fragment reads up to 128 characters from the file described by fd:
>
> unsigned count
> char *buf[128];
>
> if(_dos_read(fd, buf, 128, &count))
> printf("error reading file");
> Seebs: was this corrected in CTCR3?
No. But!
The error message was changed to "Error reading file."
So not only are the three obvious errors still there, but they are still
there despite the fact that, demonstrably, someone looked at the example.
I can't find any <dos.h> stuff in the 4th edition; it looks like it was
removed entirely. So, to add insult to injury, not only is it an extremely
buggy example with no explanation offered, but it was NEVER fixed -- at
least some of the errors were "fixed" by making a new edition in which
they are corrected.
Flipped around a bit, found a new example. 4th edition, page 264:
#define MAX_SIZE 100
/* ... */
float balance[MAX_SIZE];
/* ... */
for(i=0; i<MAX_SIZE; i++) printf("%f", balance[i]);
/* ... */
for(i=0; i<MAX_SIZE; i++) x =+ balance[i];
The reader is encouraged to try to spot errors. I only found two; can
you do better?
(Note that the last line of the above example wasn't present in the 3rd
edition, where the example appears on page 262, but the other problem
existed then too.)
... And dammit, looking it up, I found another one:
#include <stdio.h>
#define ABS(a) (a)<0 ? -(a) : (a)
void main(void)
{
printf("abs of -1 and 1: %d %d", ABS(-1), ABS(1));
}
When this program is compiled, a in the macro definition will be
substituted with the values -1 and 1. The parentheses that enclose
a ensure proper substitution in all cases.
Never mind the misdeclared main and the missing newline. Who here can
come up with a case where ABS(x) doesn't produce the expected result?
... Nevermind, it's like shooting fish in a barrel.
printf("abs(3) - 1: %d\n", ABS(3) - 1);
The forth edition points out that the () around a are needed, and illustrates
that, without them, ABS(10-20) wouldn't produce the right results -- meaning
he reviewed this example again and still didn't spot the OBVIOUS BUG.
Seriously, guys, this book is MUCH WORSE than I claimed. I thank Mr. Nilges
for making me aware of just how badly I understated the degree to which this
book is utterly unsuitable for teaching C, and if I'd had to review a book
like this, I woulda been quite tempted to argue that it was simply unsuitable
for publication without MASSIVE revisions and corrections.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
Seebs
Now 483 in 3rd edition:
> #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.
And the wrong markers for the standard header, and no main. And no
declaration in scope for gets().
It's somewhat improved in 3E, where there's declarations for
num1[80], num2[80], they're both gets'd after prompts (no newlines
or flushes, of course) and then:
printf("The sum is: %ld.", atol(num1) + atol(num2));
So it's only wrong in the usual ways (no newline on output, for instance).
(BTW, that's a DOSism, as I recall -- I believe MS-DOS printed a newline
before the prompt, so DOS programmers often habitually omitted trailing
newlines in the last output.)
4th edition fixes main's return type but does nothing else.
Seebs
> int fflush(FILE *stream);
> [Schildt claims that fflush clears input buffers.]
> Secondly, the behaviour of fflush() when passed a FILE *
> that is associated with an "input file" is undefined.
Still broken in 3rd edition. In 4th edition, the claim about the input
file is gone, but the description is questionable; what about a file opened
for both reading and writing, on which the last operation was a read rather
than a write? Then the behavior is undefined. (We could argue that this
is a file "opened for update", not "opened for writing", but not telling
the reader that you can flush a file opened for both reading and writing,
and when you can do so, is ridiculous.)
But! The 3rd edition example:
fwrite(buf, sizeof(data_type), 1, fp);
fflush(fp);
A little clumsy, but sure.
The 4th edition example:
for(i=0; i<MAX; i++) {
fwrite(buf, sizeof(data_type), 1, fp);
fflush(fp);
}
The astute reader will notice immediately that this has gone from a
slightly unimpressive example to an overtly stupid one. This should be:
fwrite(buf, sizeof(data_type), MAX, fp);
fflush(fp);
... Unless, of course, it was INTENTIONAL that it would write only the
first item in buf, MAX times. Who can say? Either it's an example of
how to do something extremely implausible, or it's another bug, INTRODUCED
in the 4th edition!