C the complete nonsense

[spinoza1111]

[Seebs - please read this, as I have a question for you at the end.]
*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);
        /* ... */
        for(i=0; i<MAX_SIZE; i++) x =+ balance;

The reader is encouraged to try to spot errors.  I only found two; can
you do better?

(1) You added some special invisible non graphic characters to make
the example not compile with several errors, or those characters were
added by the browser in a way that I have not seen occur before.

(2) It's obvious that i and x need to be defined and that the storage
is assumed to be initialized outside of the example.

(3) As Malcolm has pointed out, code snippets are not standalone and
not meant for incompetent or evil (see below) programmers to type in
uncritically. They are a somewhat harder form of text. They are
exemplary, and "no warranty, etc." You are demanding of Schildt a
level of diligence you did not show in CTCN and you have never shown
here in code examples.

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

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

**** you, asshole.

 Who here can
come up with a case where ABS(x) doesn't produce the expected result?

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

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

Very few C programmers in practice take the next step, although I did
and I taught it at Princeton and Trans-Union. This is to classify all
macros as blocks or expressions, and to always put block macros in
curly brackets and expression macros in round parentheses.

Given your low standard of care in using a switch statement with
fallthrough, I rather doubt in fact that you know or follow either
standard consistently, and given, Peter, your habit of excusing your
own slop with pleas that "it's fast and dirty and I have attention
disorder", I conclude that you are deliberately fucking with Schildt
here out of malice, envy and incompetence.

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

In terms of actual practice, as opposed to the higher standard I
taught at Princeton and Trans-Union, this is not a bug. This is
because macro code is usually accessible to its user who almost always
is the programmer who wrote the macro, and is designed under time
pressure with a finite and checkable number of uses. Any tool, of
which a macro is an example, has failure points: you don't use a
toothbrush to paint a wall.

In fact, if you happen to inherit some clown's macro library, and it's
in an #included .h file, and you don't have access to the file, and
you want to use what is claimed to be a macro that expands to an
expression, you yourself add the parentheses to make your use of the
tool safe. Likewise if you understand that the macro expands to one or
more C expressions.

If I were a practicing C programmer, I would be loth indeed to use a
macro library from you, but I would use due diligence. I would enclose
what seemed to be expressions in parentheses and what seemed to be
series of C statements in curly braces while holding my nose.

My students at TransUnion were part of Schildt's intended audience.
They were overwhelmed as assembler programmers for IBM mainframes with
the complexity and novelty of C, and did not fully comprehend the need
for so religiously bracketing "expression macros" and "block macros".
This is probably why Herb, as what you in such a self-contradictory
way call a clear writer, does describe the more common practice of
parenthesizing formal parameters and omits, at least here, the more
advanced lesson.

You simply don't exercise enough diligence in your own code, Peter,
for me to think that you do not in fact follow the Nilges rule. You
follow the Peter rule, which is to crank out slop and expect everyone
to applaud. We might, except for your evil and vicious conduct towards
others.

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.

What a complete, total, and utter fool you are. A combination of
buffoon and evil man which it would take a Shakespeare to fathom.

 

[Malcolm McLean]

See?  Flip to a random page, get an error.  Or rather, to follow up on
a previous line of thought:

        In general, every page of Schildt's books contains at least one
        error.

That's not a correct use of "In general".

"In general, there's at least one error on each page of Schildt's
books."

That means that normally we would expect one or two errors per page.
However if some smart alec says "Ha ha, the copyright page. That's a
page and it doesn't contain an error. Libel fees please." then we can
point to the "in general". Also if he happens to find a page without
any errors in it.

 

[spinoza1111]

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

So did Schildt.  So what?

He has said that he did so to learn C, which wasn't appropriate but
was overlooked because by 1999, ANSI had become privatised, corrupt
and in the service of vendors who wanted to bless a range of
incompatible implementations of C.

Furthermore, his resume online is padded. He represents himself as an
employee of, and venture capitalist for, Apple computer when in
actuality he's bought Apples and some stock.

Therefore, and because of Peter Seebach's lack of ANY academic
preparation in computer science, I conclude that Seebach joined ANSI
in order to pad his resume. That's not so bad, we all have done things
like this, but what is truly evil is that he appears to have also done
this in order to make his trivial errata stick to Herb like glue.

 

[jacob navia]

ImpalerCore a écrit :

Sheesh, some people around here have such thin skin that any little
pin prick gives 'em a hematoma. I personally don't care about
capitalization, some people do. I suppose I should have just quoted
the "killfile" comment, as that is what I directed the comment for.
If you're going to be releasing a container library, and you intend to
respond to user feedback (maybe you won't), you don't show much grace
for people who disagree with you.

I personally don't find anything wrong with the stuff that you
contribute, and anyone who contributes anything is worth more than the
criticism judging it so, whether good or bad. I normally wouldn't
have responded, but I suppose that the "killfile" comment just irked
me enough to foolishly make a response.

Look, I am just fedup with this guy that first insults me in this forum and then


.... feels irked because I do not capitalize His Name...

WTF?

He doesn't like 'thomson' in lower case?

He can use a killfile. That is all. I did not treat him of
anything!

And let's stop this ok?

 

[Seebs]

That's not a correct use of "In general".

Well, that's the problem. It's certainly an idiomatic English usage,
and one of the many ways in which it gets used.

That means that normally we would expect one or two errors per page.
However if some smart alec says "Ha ha, the copyright page. That's a
page and it doesn't contain an error. Libel fees please." then we can
point to the "in general". Also if he happens to find a page without
any errors in it.

Yes, but that's assuming one of two different meanings that "in general"
has in English.

I agree that it tends to favor the "qualified" interpretation, but it's not
the only one the phrase has.

-s

 

[Keith Thompson]

Look, I am just fedup with this guy that first insults me in this forum and then


... feels irked because I do not capitalize His Name...

WTF?

He doesn't like 'thomson' in lower case?

He can use a killfile. That is all. I did not treat him of
anything!

And let's stop this ok?

jacob, I sent you a response to your previous article by e-mail.
Do you intend to reply?

You can stop this any time you like. I insulted you exactly once,
nearly seven months ago, in direct response you what I considered
to be an unwarranted insult from you. Why are you so obsessed with
that one minor incident?

 

[Malcolm McLean]

Well, that's the problem.  It's certainly an idiomatic English usage,
and one of the many ways in which it gets used.


Yes, but that's assuming one of two different meanings that "in general"
has in English.

I agree that it tends to favor the "qualified" interpretation, but it's not
the only one the phrase has.

The phrase can be used "he is interested in snakes in general", that
is, he is interested in all snakes and in the things which they have
in common, as opposed to being interested in adders, for example.

However it can't be used to mean "always, without exception". "In
general, compiled languages are faster than interpreted ones" does not
mean "always, without exception, a compiled language is faster than an
interpreted one"; it means the opposite of that.

 

[Seebs]

However it can't be used to mean "always, without exception". "In
general, compiled languages are faster than interpreted ones" does not
mean "always, without exception, a compiled language is faster than an
interpreted one"; it means the opposite of that.

Actually, it doesn't, because the opposite of that would be "always,
without exception, an interpreted language is faster than a compiled one."

Nonetheless, whether it's the most common connotation or not:

1. "In general" sometimes means "always".
2. Even if it doesn't, the statement is still not something which belongs
in the book regardless of whether it's a tutorial or a reference.
3. You have still offered no possible justification for arguing that the
book is not intended as a reference, given that it is sold as one, marketed
as one, described as one, and structured as one, and the bulk of the material
is in a typical reference format.

The only objection to calling it a "reference" is that the code and
descriptions are both stunningly error-prone.

-s

 

[lawrence.jones]

Yes.

As I said, whether it is a postfix operator is irrelevant. It
looks like an infix operator to me.

If a and b were both expressions, then it would be an infix operator.
But they're not; so it's not, either. Strictly speaking, "b" is not
really an operand as it is not in any way evaluated; it's really just
part of the operator.

 

[Malcolm McLean]

3.  You have still offered no possible justification for arguing that the
book is not intended as a reference, given that it is sold as one, marketed
as one, described as one, and structured as one, and the bulk of the material
is in a typical reference format.

Here's the very first review on Amazon:

"A tutorial, NOT a reference"

Having come across Schild's book when starting out as a programmer I
believed it to be one of the best I've read. In this respect it is
very good for a beginner, but searching now for a reference manual
(I've misplaced the misnomer: "C, A Complete Reference") as a
more experienced programmer I realise this is really a
tutorial.

I'm not the only person to say that.

 

[Seebs]

Here's the very first review on Amazon:

"A tutorial, NOT a reference"

Having come across Schild's book when starting out as a programmer I
believed it to be one of the best I've read. In this respect it is
very good for a beginner, but searching now for a reference manual
(I've misplaced the misnomer: "C, A Complete Reference") as a
more experienced programmer I realise this is really a
tutorial.

I'm not the only person to say that.

Okay, so, you're saying that the book is marketed and sold fraudulently,
and that all the material in the preface, and the huge bulk of material
which consists of lists of functions and descriptions of what they do,
with no explanation of why or how one would use them, is just an extremely
bad tutorial?

Hint: Amazon reviews are not authoritative. The book itself is clearly
structured as, organized as, sold as, and labeled as a reference. It claims
to be "a comprehensive desktop reference". Many other reviewers claim that
it's the thing you keep on your desk to look things up -- and all of them
are comparative novice programmers who are unlikely to know that the poor
choice of a reference is directly tied to the security bugs and crashes
they keep getting.

But frankly, as a tutorial, it's *worse*, because it consistently teaches
bad habits, explains things in ways that are often more complicated than
correct alternatives, and leaves the reader completely confused about how
C environments work. So I'm not sold on that interpretation at all, but
even if I were, it wouldn't make the book in any way up to minimal acceptable
standards.

Okay, more random examples:

This statement displays the length of the multibyte character
pointed to by mb:

printf("%d", mblen(mb, 2));

Does it? Because the description above says:

The mblen() function returns the length (in bytes) of a multibyte
character pointed to by /str/. Only the first /size/ number of
characters are examined. It returns -1 on error.

("str" and "size" are italicized.)

Okay, so. First off, "/size/ number of characters" is just plain incoherent;
it should just be "/size/ characters". (Imagine that size is 2; would you
say that it returns the length of "the first 2 number of characters"? No.)
But wait, that's still wrong. It doesn't examine at most two *characters*;
it examines at most two *bytes*. What this means is that mblen(mb, 2) cannot
correctly tell you the length of a multibyte character that is over two
*bytes* wrong.

So.

The description of the function is ungrammatical, and wrong, and the example
is incorrect as well.

Typical. The whole book is like this.

I suppose at this point, the obvious thing would be for me to try to take
a day off from my regular work and write a more detailed summary of the
kinds of things that are wrong in this book. It seems like a huge waste
of time, but at least I'll finally be free of people complaining that
something I wrote nearly 15 years ago before I had any real experience
writing isn't written well enough, even though the substantive claim of
the page ("this book is full of nonsense") stands.

-s

 

[Malcolm McLean]

Hint:  Amazon reviews are not authoritative.

No, but the fact that two people independently described the book as
"more of a tutorial than a reference", myself and the Amazon reviewer,
is very significant. One person might say something with no real basis
in fact, but the odds on two people making exactly the same mistake
are very low, unless the book does indeed have features which would
cause a reasonable person to regard it as more tutorial in nature.

 

[Willem]

Malcolm McLean wrote:
) No, but the fact that two people independently described the book as
) "more of a tutorial than a reference", myself and the Amazon reviewer,
) is very significant. One person might say something with no real basis
) in fact, but the odds on two people making exactly the same mistake
) are very low, unless the book does indeed have features which would
) cause a reasonable person to regard it as more tutorial in nature.

Or unless there aren't that many choices of book type, and a lot of
reviews. Which there aren't, and are. Sheesh.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Seebs]

No, but the fact that two people independently described the book as
"more of a tutorial than a reference", myself and the Amazon reviewer,
is very significant.

It would be if you had ever seen the book. As is, didn't you give his
review as your *REASON* for holding your position?

One person might say something with no real basis
in fact, but the odds on two people making exactly the same mistake
are very low, unless the book does indeed have features which would
cause a reasonable person to regard it as more tutorial in nature.

A reasonable person *who has not actually read the whole book*, yes.

The book starts out with some tutorial material, *then continues on
into a very comprehensive reference*. That's the big selling point.
That's why people say you should have a copy on your desk. If only
the reference were *accurate*, it'd be great.

But the fact is, while the book certainly does start with a tutorial,
the bulk of it is reference material and examples, not a tutorial, and
it is marketed as a reference because it is one.

Sadly, it's a very bad reference. But that's okay, it's a worse tutorial.

-s

 

[Keith Thompson]

No, but the fact that two people independently described the book as
"more of a tutorial than a reference", myself and the Amazon reviewer,
is very significant. One person might say something with no real basis
in fact, but the odds on two people making exactly the same mistake
are very low, unless the book does indeed have features which would
cause a reasonable person to regard it as more tutorial in nature.

Ok, so what's *your* basis for saying it's "more of a tutorial than a
reference"? Quoting what you wrote upthread:
| I think the title of Schildt's book invites misplaced criticism.
| Whilst the book is entitled a "reference" it is in fact a tutorial.

and later:
| I haven't actually read the book. However that's the impression I
| gain.

So we have two sources for the claim, one from someone who hasn't read
the book, and another from someone who wrote a review on Amazon. I
don't find either of them persuasive.

Surely Schildt knew the title of the book he was writing, and Shildt
himself has been quoted here saying that it's a reference.

 

[Malcolm McLean]

It would be if you had ever seen the book.  As is, didn't you give his
review as your *REASON* for holding your position?

I did, but what happened was I thought I'd better actually look at the
book, so I typed the title in Google. The first hit was Amazon, and
the first revew said "A tutorial, NOT a reference". This was a such a
coincidence that obviously the first thing I did was cut and paste and
post it.

A reference isn't designed to be read. It's intended to be consulted
to check facts, for instance if you forget whether the number of
elements is the second or the thrid parameter to qsort(), or to check
if the standard says anything about calling sin() with an argument
outside the range -2PI to 2PI radians. It's pretty obvious from the
snippets that the book isn't written like that sort of work.

 

[Seebs]

A reference isn't designed to be read. It's intended to be consulted
to check facts, for instance if you forget whether the number of
elements is the second or the thrid parameter to qsort(), or to check
if the standard says anything about calling sin() with an argument
outside the range -2PI to 2PI radians. It's pretty obvious from the
snippets that the book isn't written like that sort of work.

Again, just plain wrong. The snippets of text are from explanatory
material, but the code fragments are usually from sample code attached
to *referenge* material -- much like many man pages have a section
labeled "EXAMPLES".

The bulk of the interesting material consists of something pretty much
in the same category as a UNIX man page. A typical example:

(the first two lines are bold, large print, outdented, to serve as a
heading)
#include <stdio.h>
int fscanf(FILE *stream, const char *format, ...);

The fscanf() function works exactly like the scanf()
function, but it reads the information from the stream
specified by /stream/ instead of stdin. See the scanf()
function for details.

The fscanf() function returns the number of arguments
actually assigned values. This number does not include
skipped fields. A return value of EOF means that a failure
occurred before the first assignment was made.

Example

This code fragment reads a string and a float from the
stream fp.

char str[80];
float f;

fscanf(fp, "%s%f", str, &f);

Related Functions
scanf(), fprintf()

That's a reference, not a tutorial. Sure, the book contains tutorial
material, but the above is not any kind of a tutorial; it's one entry
among many, all of which are sorted alphabetically by name, in chapters
organized roughly by functionality.

Schildt says it's a reference. The contents of the book make it clear
that it is intended to serve as a reference, not just as a book to be
read and then you're done with it. Many reviewers, and the book itself,
make much of the fact that even once you've read the tutorial material,
you can continue to use the book as a reference because it has all
this reference material in it.

It's not particularly a GOOD reference, but a reference it is.

-s

 

[Seebs]

If a and b were both expressions, then it would be an infix operator.
But they're not; so it's not, either. Strictly speaking, "b" is not
really an operand as it is not in any way evaluated; it's really just
part of the operator.

In this case, I think you should have harsh words with whoever edited
C99*, because the standard clearly refers to b as "an operand".

.... That said, what you say here aligns with my expectations; I view
".b" as a postfix operator rather than a binary operator in the normal sense
of things, but I'm obliged to grant that the standard itself appears
to refer to "." as being an operator with two operands.

-s
[*] It's funny because it was mostly edited by Larry Jones. Who, despite
the nitpicking, did an excellent job.

 

[Keith Thompson]

If a and b were both expressions, then it would be an infix operator.
But they're not; so it's not, either. Strictly speaking, "b" is not
really an operand as it is not in any way evaluated; it's really just
part of the operator.

Strictly speaking, it's an operand because it satisfies the
standard's definition of the word "operand" (C99 6.4.6p2).

I prefer your way of expressing it, but we're stuck with the
Standard's definition.

Given that "." has two operands, and that it appears between them,
it does seem odd to call it a postfix operator rather than an
infix operator. I suspect it's classified as postfix because it
makes the grammar simpler, in much the same way that "typedef"
is classified as a storage-class specifier.

 

[Phil Carmody]

If a and b were both expressions, then it would be an infix operator.
But they're not; so it's not, either. Strictly speaking, "b" is not
really an operand as it is not in any way evaluated; it's really just
part of the operator.

Currying envy...

Phil