C the complete nonsense

[Bill Reid]

That it is a confusing and inconsistent backwater is not a *mitigating*
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...

 

[spinoza1111]

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.

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.

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.

 

[Keith Thompson]

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]

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
broken that several skilled professionals looking at it can *miss* some of
the errors, because they're masked by others.

-s

 

[spinoza1111]

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.

 

[spinoza1111]

And you decided to do so?  Ok, whatever.

Bite me, Snidely.

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.

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

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.

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 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 Librorum Prohibitorum-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 <[email protected]> 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.

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.

Not correctly.


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.

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.

 

[spinoza1111]

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

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

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

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

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.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <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]

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

 

[spinoza1111]

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?

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.

--
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 1utchar(a[i&15]);break;}}}

 

[Seebs]

Prediction fulfilled. (See Message-ID:
<[email protected]> 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?!).

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.

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]

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.

 

[spinoza1111]

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 <[email protected]> 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.

 

[spinoza1111]

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.

 

[Phil Carmody]

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

 

[Phil Carmody]

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.

Phil

 

[Phil Carmody]

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

Actual, the structure member operator is a postfix operator.

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

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

The suffix of a "." operator isn't what I'd call an "operand".

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.

Phil

 

[spinoza1111]

I think that's shooting fish in a barrel territory.


And also a bit of concern about why he would jump in and make silly
claims ("it's a tutorial, not a reference" -- HUH?!).


Yes.  The commentary can only be evaluated in terms of the thing commented
on.


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.

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.

 

[Phil Carmody]

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?

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

Phil