C the complete nonsense

[spinoza1111]

Hee.

Watch it with that tendency towards ig knorant laughter. See below.
Yes, we. I think I speak for the smartest people here when we say that
we're tired of your little crusade because it's a pig wrestle and
bandwidth hog.

"kneed"?

Highly literate people kneed to use their nowledge in order to make
dissonances intended to confuse less literate. It is a higher and more
involved form of shibboleth in that it's strictly in the service of
humor, and is "knot" intended to humiliate and exclude.

<snippety snip>

 

[Nick Keighley]

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.

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

yes. Though computer science seems to have a least two common usages
for the term "heap". Sedgewick calls a tree satisfying something
called the "heap condition" (the tree is sorted in aparticular
fashion) a "heap data structure". Knuth mentions the term "heap" in
your sense (in the sense of dynamic storage allocation) but only as a
terminological aside.

I prefer not to use the term heap as it carries unnecessary
implications about implementation.

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.

no not really

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

<snip>


--
"When my companion said he wanted a beer he wasn't just thinking of
the particular beverage but of the experience it represents. The
beer,
the seedy bar, grizzelled space traders haggling over dubious goods,
greasy tables, loud music, women of easy virtue. Beer as a symbol."

 

[Tim Streater]

I don't think Schildt's books are great. I do think that people have a
right to publish and be then free of criticism by their educational
and programming inferiors, ...

Stuff and nonsense Spinny (as usual), and in any case those making the
criticisms don't fall into that category (you snob).

 

[Nick Keighley]

it's noticable that C++ doesn't allow operator-dot to be overloaded,
but it does allow operator-> to be overloaded

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 C standard lists the "<" operator in a section titled
"Relational operators".  Do you consider "<" to be a binary
operator?

[...]

"Binary operator" does not have, any more than many English
expressions, a fixed meaning.

I thought it did. I thought it meant "taking two operands"

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.

?

aren't &= |= ^= logical assignment operators?

 

[Malcolm McLean]

Stuff and nonsense Spinny (as usual), and in any case those making the
criticisms don't fall into that category (you snob).

The idea that you have to have a higher or equivalent academic
qualification to the author in order to be allowed to make a comment
on a book is not, I think, a flyer.

On the other hand if some of your criticisms are wrong, are pretty
clearly shown to be wrong, and you persist in insisting that they are
right, then you lack credibility as a critic.

 

[Alexander Bartolich]

[...]
aren't &= |= ^= logical assignment operators?

The standard calls
& the "bitwise AND operator"
| the "bitwise inclusive OR operator"
^ the "bitwise exclusive OR operator"

There are also logical operators, but they are different.
&& is the "logical AND operator"
|| is the "logical OR operator"

So, no, there are no "logical assignment operators" in C.
(The standard speaks of "compound assignment".)

--

 

[Tim Streater]

The idea that you have to have a higher or equivalent academic
qualification to the author in order to be allowed to make a comment
on a book is not, I think, a flyer.

On the other hand if some of your criticisms are wrong, are pretty
clearly shown to be wrong, and you persist in insisting that they are
right, then you lack credibility as a critic.

Yes, I agree. But I don't think that has been happening in this instance.

 

[Nick Keighley]

Peter, the issue here isn't Schildt's book. It is "C: the Complete
Nonsense", not "C: the Complete Reference". [...]
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".

don't do it!

I do not accept arguments of this form. "My classmates are stupid
therefore I am smart" is not a valid inference.

I don't see them as being of the same form

It is now a Reception section, but overgeneralizes the canard to apply
to all of Schildt's output, not just CTCR.

does wikipedia do this? I think Seebs critique is squarely aimed at a
particular document. Though if you want to start discussing the errors
in "Annotated ANSI C Standard" I'd be happy to open the batting...
Apparently he even quotes the standard incorrectly at one point.

You can do that, of course. However, to do an acceptable job, you need
to provide all of what you think are errors,

no. Once the error level is sufficiently high the reader can see it is
a bad book. Does it matter if a boat has 15 holes or 17?

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.

I assure you it won't.

I don't think your sort of harrassment should be allowed to succeed.

 

[Nick Keighley]

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

heavens to betsy.

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

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


But renaming "endptr" to "end" (and then passing "&end" as an
argument, so the caller's "end" is a char* and the callee's "end" is a
char**)?

that sounds a bit bad. I don't mind a char** being called end but I do
object to multiple variables called end having different types in
different parts of the program. Seems to be asking for trouble.

 The only explanation I can think of is that he simplified it
to the point of incorrectness, without even realizing the distinction
between char* and char**.

I think that involves a bit of mind reading. If not mind writing.

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

I'm not convinced he's wrong here. Beginners aren't usually happy with
standards (I like them, but I'm strange!) so paraphrasing standardese
is *exactly* what he's supposed to be doing. Provided he makes it
clearer... The difficulty is explaining clearly and simply what the
example program does and describign exactly what strtol() does in all
cases. I think I'd tackle them separately. First explain the noddy
program then trot out the a paraphrase (or a straight quote) from the
standrad.

 

[Nick Keighley]

It is common to collapse this distinction temporarily in teaching.

and when does he undo this particular example of lying to children?
The trouble with giving wrong examples is they later have to be
unlearned

You don't know what he knows.
yes



Translation: it is correct.


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

some of us have memories. I remember being a child and I remember
being a newbie.

But strangely, knor

why have you started putting ks on the front of words? Is this 15th
century spelling or something?

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

yeah? cite?

English cannot be used as a formal metalanguage for C,

slightly formalised english can though.
The alternatives are rather dense.

therefore
anything that is said in English about C (such as what's set when end
is set) can be interpreted as wrong by hostile dweebs.

I don't think this is happening though

We now kneed you to blank or remove C: the Complete Nonsense. You
could do this silly set of silly operations on the example code of any
computer book,

no, not really.

and we have learned that you produce code that is far
less competent. We're tired of you wasting bandwidth and patience.

"we are a grandmother!"
Margaret Hilda Thatcher


--
Matthew 23:24
KJV:
[23] Woe unto you, scribes and Pharisees, hypocrites! for ye pay
tithe
of mint and anise and cummin, and have omitted the weightier matters
of the law, judgment, mercy, and faith: these ought ye to have done,
and not to leave the other undone.
[24] Ye blind guides, which strain at a gnat, and swallow a camel.

 

[Nick Keighley]

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

can we gather up all the examples of errors and post them on a web
site?

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



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

1. Parenthesize all formal parameters

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

this is standard practice amongst experienced C programmers

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

Although I do this consistently, this and other standards I use make
my code strange to mortal men,

I can see that!

and because most programmers code
macros strictly for their own use,

well no. Teams of programmers use each others macros and libraries
sometimes have macros. Macros are /not/ usually written "strictly for
the writer's use"

this standard is seldom followed by
programmers in practice.

well your standard isn't (thank random_deity())

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

perhaps he doesn't take criticism well?

 

[blmblm]

[ snip ]

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.

Strange. The copy of Seeb's post delivered to me by the news server
I use contained no such characters, and when I saved the code in a
file and added appropriate declarations, etc. (without changing the
above lines), it compiled fine. Could Google's interface be adding
those invisible(?) characters? I've noticed that posts made from
Google's posting interface seem to be sent out in quoted-printable
encoding, and that *does* include some not-7-bit-ASCII characters [*].
Maybe they're doing something similar with displayed posts?

[*] Quite annoying to those of using antique newsreaders that don't
cope well with anything but 7-bit ASCII, but I cope, and of course
it's my choice to keep using trn.

[ snip ]

 

[Nick Keighley]

The chief flaw in C:TCN is that in doesn't give enough of the examples -- but
not that it overclaims.  It underclaims, and fairly seriously so.

that is more and more looking like its major flaw. If CTCN was updated
it would be *more* devastating.

To avoid too much repitition there needs to be a "generic" errors
section.

Pretty much all the examples commit the following basic errors
- incorrect bracketing of standard headers
- incorrect return value from main()
- non-portable value passed to exit()

I nearly said "insufficient error checking" but I think that needs to
be tackled on a case by case basis

 

[spinoza1111]

that is more and more looking like its major flaw. If CTCN was updated
it would be *more* devastating.

To avoid too much repitition there needs to be a "generic" errors
section.

   Pretty much all the examples commit the following basic errors
       - incorrect bracketing of standard headers
       - incorrect return value from main()
       - non-portable value passed to exit()

I nearly said "insufficient error checking" but I think that needs to
be tackled on a case by case basis

Nobody here is qualified to do this, I'm afraid, for two reasons:

1. The most rabid critics have shown here in their own code that they
don't have enough programming competence. Seebach as far as I can tell
repeatedly posts buggy code. Heathfield is more competent, but limited
by a similar lack of education; for example, his "linked list"
consists of data rather than pointers in C Unleashed.

2. The goal is to "get" Schildt still, which means that in most
cases, the most uncharitable interpretations of his code and text will
be selected. We've seen that to a great extent in text, there are n>1
interpretations, as in the two interpretations possible today of "long
integer" (32 bit in C: 64 bit practically everywhere else). But this
also occurs in code, where Seebach and Heathfield continue to make
snarky remarks of the form "find the many bugs in this code", and the
bugs are merely contextual. It's still Open Season and Open Source on
Schildt, because the effort to "get" him includes requests that others
participate.

 

[spinoza1111]

can we gather up all the examples of errors and post them on a web
site?

No. This is big-character, late Cultural Revolution, digital Maoism.
By 1974 decent teachers and doctors would wake up and find their
village plastered with signs denouncing them. Let Peter take
responsibility for the messes he makes.

riight...

You got it.

this is standard practice amongst experienced C programmers

In my experience, dear heart, that's what they "say" they do. Then,
when you look at their code, they didn't do it because each particular
program, they say, was meant to be "fast and dirty". In each case,
management had created an artificial time scarcity.

<puke>

Why puke? The "inelegance" shows a strange charity for computers and
their picocycles which is missing in the treatment of Schildt, or
newbies, or posters from China here. I like "wasting" computer time in
a good cause, such as an interpretive program with rules that can be
changed by the user.

I can see that!
Good.


well no. Teams of programmers use each others macros and libraries
sometimes have macros. Macros are /not/ usually written "strictly for
the writer's use"

....and wise programmers will parenthesize and bracket because "teams"
in corporate practice are primitive, regressed and devolved neo-tribal
entities in which oppression of all by all does management's work for
them, allowing the suits to literally talk a different language and
inhabit a different world. They become, in Elvis Costello's words, the
gods of antiquity who have feasts on the backsides of beasts.

well your standard isn't (thank random_deity())

My, we are snarky, aren't we. The trouble being that my standard is
the only way to code truly reusable preprocessor macros. I've seen
what passes for quality here in Seebach's and Heathfield's garbage,
and they've been so long livin' in garbage that something merely
workmanlike seems very strange to them.

perhaps he doesn't take criticism well?

Nobody, except the most demoralized sort of American employees,
expects 15 years of unrelenting criticism based on such a trivial
source. People have the right to a quantum of dignity and respect, and
this is infinitely more important than some horseshit programming
language.

 

[James Harris]

[ snip ]

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.

Strange.  The copy of Seeb's post delivered to me by the news server
I use contained no such characters,

Given that the example was apparently as shown in a book I doubt there
were nonprintable characters. My guess is that Edward Nilges was
making a joke or that he was guessing.

Errors?

1. Neither \n nor other whitespace printed between each balance.
2. MAX_SIZE balances processed even if there are fewer.
3. The =+ should probably be +=.

James

 

[James Harris]

that is more and more looking like its major flaw. If CTCN was updated
it would be *more* devastating.

Judging by the faults Richard is finding and, most importantly, Edward
is neither challenging nor refuting, it's beginning to look like an
updated CTCN would be as long as the book it is criticising!

James

 

[Keith Thompson]

this is standard practice amongst experienced C programmers

[...]

He misses one thing: for macros that expand to multiple statements,
the definition should be surrounded with "do { ... } while (0)".
Failing to do so can cause some problems with "else". (This is in the
FAQ, but the site appears to be down at the moment.)

These aren't universal rules; for macros that mess around with the
syntax, it's not always possible to follow them. Such macros should
usually be avoided, but they can sometimes be useful.

 

[Keith Thompson]

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?

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

[...]

The use of "=+" is interesting.

Very early versions of C (pre-K&R1) used "=+" as a compound assignment
operator, and likewise for the the others ("=-", "=*", etc.). These
were switched to their modern forms ("+=", "-=", "*=") because of
things like
i=-1;
which, under the old rules, would decrement i rather than assigning
the value -1 to i.

The statement
x =+ balance;
is syntactically correct; it means
x = +balance;

 

[Seebs]

On the other hand if some of your criticisms are wrong, are pretty
clearly shown to be wrong, and you persist in insisting that they are
right, then you lack credibility as a critic.

Oh, totally agreed. However, you simply haven't shown that they were
wrong. You've shown that one of them relies on a questionable interpretation
of English, which I grant.

But the bulk of the complaints are not wrong, and are not things that can
be explained away as simple typos.

Furthermore, as demonstrated by the 4th edition:

SCHILDT GRANTS THAT THE CRITICISMS ARE CORRECT.

Look specifically at my criticism of getchar() (page 314 in the 3rd edition).

In the 3rd edition, the described sentence was present in both getchar()
and getc(). (I do not consider the duplication of text between functions to
be a bug; this is a reference, and each entry should be reasonably
self-contained.)

In the 4th edition, the one I complained about was removed, but the identical
sentence in the description of getc() was not.

So we have it from the horse's mouth: The criticisms were, by and large,
valid, and most of them have been "corrected" by Schildt. Sadly, he didn't
understand them -- the example code for getchar() is still useless, in the
same way it used to be.

-s