C the complete nonsense

[Seebs]

(Did *anyone* "approve" of that? Dismiss it as a minor fencepost
error of the sort people make when not reviewing or checking code,
sure. *Approve*? I sure don't think so.)

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.

This one's actually fixed in the third edition! That's surprising, since
the 3rd edition seems to have fixed very few bugs.

On the other hand, the example is more fundamentally broken. The structure
of the "scheduler" is an array[MAX] of char *. As you enter appointments,
they are appended to the list, and "spos" is incremented. As you delete
appointments, "rpos" is incremented. Note that no deallocation occurs. Also,
there's no reuse of any sort. So delete() just looks like:
if((p=qretrieve())==NULL) return;
printf("%s\n", p);
where qretrieve() is a destructive removal of exactly the first item in the
list, never any other. And no deallocation occurs. (delete() could have
reasonably freed p after printing it.) The only change I see in 4th edition
is that it's been renamed to delete_ap(), and he's added a cast to malloc();
basically, he's made it more C++ friendly.

-s

 

[Seebs]

spinoza1111 wrote:
<snip>

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.

It's nice for Nilges to come out and say that his fundamental reason for
objecting to my page is that he wants to be able to commit a felony-level
unauthorized access to someone else's computers. (Hint: Once you're banned,
trying to sneak around the ban is, in fact, usually a felony, albeit not
one the cops are likely to pursue.)

However, he's wrong; there are other pages that support the same point just
as well.

It doesn't take a genius to work out why.

But it might take someone to figure out WHY the "/2" is there.

-s

 

[Seebs]

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

So did Schildt. So what?

In fact, so did everyone I know of. In fact, I'm the only person I know
to have been given a waiver of the fees (I was flat broke at the time) to
allow me to continue attending meetings and voting based on my contributions,
rather than based on sending in money. (Only one year, but hey, it's a
data point.)

The difference is that Schildt paid the money for membership, then never
attended meetings or participated in any way that anyone I ever talked to is
aware of. He paid money for the recognition and status. Me, I went to
meetings and put in time and effort trying to find ways to improve the
language, working on defects, suggesting resolutions to wording problems, and
otherwise actually DOING STUFF.

-s

 

[Seebs]

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.

WTF.

Nilges apparently can't use Google.

Anyway...

http://www.ibm.com/developerworks/power/library/pa-ctypes1/

I assume Nilges is now gonna send a bunch of complaints to the dW people
bitching about this. I apologize in advance to the dW editors, but it's
not as though it would have taken anyone in the world but Nilges more than
a few seconds to find these.

http://www.ibm.com/developerworks/library/l-c99.html
http://www.ibm.com/developerworks/library/pa-spec3.html

(For the curious among CLC: I was laid off in 2003, and spent a couple of
years working primarily as a freelance writer. The economy improved, and in
2007 I was head-hunted by the same people as soon as they found out I might
be open to employment.)

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.

Did you feed it more than 79 upper case characters? Because I get the
feeling the "crashes due to gets being stupid" are intended to be overlooked.
(If it's something else, it's too subtle for me to get before breakfast.)

-s

 

[Seebs]

The text content of the cover is part of the galleys sent
to the author for fact checking and approval.

And indeed, we even get some influence. Not as much as we might like;
"Beginning Portable Shell Scripting" was named "Beginning" despite my
objections. I wrote a book in the process of which I, and my tech reviewer
(an autoconf maintainer!) learned a great deal about shell programming and
shell portability, but because the series roadmap called for a "beginning"
book, it got tagged as such.

I did get them to not call it a "Linux" book, though -- I felt that calling
it "Linux" would rather undermine the point of writing a book about portable
code.

-s

 

[Seebs]

I haven't actually read the book. However that's the impression I
gain.

Your impression is completely wrong.

It is primarily a reference, it is sold as such, and it is structured
as such.

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.

It wouldn't be a good criticism, though. The book is well-structured
in that regard; it begins with tutorial material and then provides a
large and fairly complete reference section.

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

The main problem with the existing page is that it barely scratches
the surface of the insanity; see the other examples we've been posting
recently.

Seriously. Open it to a random page, get nonsense, more often than not.

You said it.

Yes. Because it was not offered as a "professional-quality book review".
It was a quick patch to stem the bleeding of the endless flood of newbies
coming to clc and not having any idea why none of their code worked and many
of the examples in their book wouldn't even compile.

It's very unprofessional to make bug reports in a
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.

Except that you have yet to show that even ONE of the nitpicks is actually
wrong -- some of them may be overly picky, or not the most persuasive or
best examples, but that doesn't make them "not even right".

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.

Yes. Or a mediocre criticism.

I think, though, that your complaints about the tone of C:TCN are misplaced.
This is a spectacularly bad book. Have you noticed the "random quote from
C:TCR" game has yet to produce a randomly selected code sample which did NOT
have at least one or two bugs?

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.

-s

 

[Keith Thompson]

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;

Why the division by 2?

Hmm, I think I see some possible logic here. (unsigned)ltime could
exceed INT_MAX. Dividing by 2 avoids overflow. And yes, the cast is
necessary to achieve this (unless you use another temporary variable).
Does the text explain this?

(My first thought was that the system clock might be updated only once
every 2 seconds, and the division allows it to cover all values in the
range -- not that that would be particularly helpful anyway.)

The spacing implies that the cast applies to "ltime/2"; in fact, it
applies to "ltime", and the result of the cast is then divided by 2.
It's like writing "x * y+z".

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;

Yes, the word "randomly" is incorrect.

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

Poor style, but not an error, since the result will be implicitly
converted. There's some risk of overflow if time_t is unsigned and at
least as wide as long, but if you assume a particular representation
(say, seconds since 1970), that's not an issue until some particular
time in the future (say, 2038).

5) assigning an unsigned int value to an int object;
6) passing an int value to srand(), which expects an unsigned int;

For both 5 and 6, the values will be implicitly converted. But yes,
declaring the objects to be of the expected type in the first place
would have been much better style.

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.

You ran it three times within a second. That's not a fatal flaw
in a small demonstration program. There's no good *portable* way
to choose an argument for srand(); using time(NULL) is reasonable.
(If you really care about randomness, of course, you'll need to
use something system-specific.)

 

[Keith Thompson]

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.

*How many* upper case characters?

You didn't mention that passing a char value to toupper() is
dangerous; if plain char is signed, and the value is negative (and
not equal to EOF), the behavior is undefined. One might argue that
toupper() is poorly designed, and I'd agree, but if you're teaching
a flawed language there's no excuse for ignoring the flaws.

 

[Keith Thompson]

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.

People have been encouraging Nilges to behave reasonably for many
years. It never works.

 

[Keith Thompson]

Let's play the random game again.

Schildt's CTCR2e, p138. Note that the opening comment is Schildt's,
not mine!

[snip]

I'm just curious, what are the rules of the random game? Do you
choose a random page and find an error on that page? What do you do
if you can't find an error on the page, and how often does that
happen?

Try page (generating a random number) 464.

 

[ImpalerCore]

Keith Thompson a écrit :




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!

This is not the kind of attitude that will lead people to want to use
your container library.

 

[Malcolm McLean]

Except that you have yet to show that even ONE of the nitpicks is actually
wrong -- some of them may be overly picky, or not the most persuasive or
best examples, but that doesn't make them "not even right".

Take the very first. The term "In general" means, "there are a few
specific cases where this does not apply, but these aren't
sufficiently important to concern us here". That's the case with non-
twos complement negative numbers. Nitpick one is pretty indisputably
wrong.
Of course you can sensibly argue that one's complement and sign-
magnitude should be covered. There are often choices which have to be
made, and you have to balance coverage of all the material with
brevity. But it's not an error in the sense that you mean it.

 

[bartc]

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

Actual, the structure member operator is a postfix operator.

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

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

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

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

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

Wouldn't "a . b" be written "a b ." if "." was a postfix op with two
operands?

 

[Ben Pfaff]

Wouldn't "a . b" be written "a b ." if "." was a postfix op with two
operands?

Yes.

As I said, whether it is a postfix operator is irrelevant. It
looks like an infix operator to me. In my opinion, it just fits
conveniently in the grammar with the postfix operators.

 

[Seebs]

I'm just curious, what are the rules of the random game? Do you
choose a random page and find an error on that page? What do you do
if you can't find an error on the page, and how often does that
happen?

I've not yet had it happen.

Try page (generating a random number) 464.

In the 3rd edition, this covers "short __far _lineto(short x, short y);",
about which I can't tell you much, except that it ends with:

_lineto(600, 400);
getche();
_setvideomode(_DEFAULTMODE);

(we'll give him a pass on the "void main" since this is obviously
system-specific code.)

However, I think this may be a bug. According to his documentation
of getche(), it takes a character from input immediately (without
waiting for a return), and echoes the character you enter to the screen.
I do not know what would happen if you called this while in a video
mode drawing stuff directly, but I wouldn't expect it to be pleasant;
my guess is this should have been getch(). (Anyone got an old DOS
system with <conio.h> and <graph.h> on which to test it?)

In the 4th edition, this is the page covering strtol and strtod.
We have:

This function reads base 10 numbers from standard input and
returns their long equivalent:

long int read_long(void)
{
char start[80], *end;
printf("Enter a number: ");
gets(start);
return strtol(start, &end, 10);
}

Just the usual:
* printf with no newline and no flush.
* gets into a finite-length buffer.
* no error checking at all.

Note that the "printf with no newline and no flush" thing isn't just
us being randomly picky. On many implementations, NOTHING HAPPENS until
you either flush or write a newline. Meaning that all of these
prompts printed without a flush don't show up to the user, so if you
run this code on many systems, you get no visible prompt -- and the next
time output is printed that includes a newline, or when the stream is
next flushed, it gets the prompt attached to whatever's happening then.

The big flaw, of course, is that this example is TOTALLY USELESS, because
it doesn't show you how to *use* strtol. A good example would do
things like:
* show you how to use 'end' to detect parsing errors (for
instance, if end == start, there was no number at all)
* possibly some kind of illustration of how to check errno,
including setting it to 0 before making the call.

Also, it wouldn't hurt if the description of strtol were correct; while
this is, strictly speaking, on page 463, it's a great quote:

Finally, end is set to point to the remainder, if
any, of the original string. This means that if strtol()
is called with " 100 Pliers", the value 100L will be returned,
and end will point to the space that precedes "Pliers".

Very good, only it's not true. What's set to point to the remainder
of the original string is *the pointer pointed to by end, if end is
non-NULL*. That's a pretty significant mistake to make. The
example for strtod actually sort of shows how to use the "end" value, but
the description of it is still wrong.

-s

 

[Keith Thompson]

Take the very first. The term "In general" means, "there are a few
specific cases where this does not apply, but these aren't
sufficiently important to concern us here". That's the case with non-
twos complement negative numbers. Nitpick one is pretty indisputably
wrong.

Nope.

That's one interpretation of the phrase "in general". Another
perfectly reasonable interpretation is that "in general" means
"always".

dictionary.com's first two definitions of "general" are:

1. of or pertaining to all persons or things belonging to a group
or category: a general meeting of the employees.

2. of, pertaining to, or true of such persons or things in the
main, with possible exceptions; common to most; prevalent;
usual: the general mood of the people.

Schildt may well have meant "usually" rather than "always", but a
significant number of people have misunderstood him because of his
use of the word "general". I suggest that, as a professional writer,
it is Schildt's responsibility to avoid such misunderstandings.
I might grant that this particular criticism is overly picky,
but not that it's wrong, and certainly not that it's "pretty
indisputably wrong".

Are any of the other criticisms demonstrably wrong?

[...]

 

[Seebs]

Take the very first. The term "In general" means, "there are a few
specific cases where this does not apply, but these aren't
sufficiently important to concern us here".

No, it means either that or "always". Both usages exist in English, and
the phrase is ambiguous.

That's the case with non-
twos complement negative numbers.

I'm not sure of this.

Nitpick one is pretty indisputably wrong.

No, it's ambiguous; I interpreted an ambiguous phrase in a different way.

But yes, I could nitpick that one much better now. I could point out that
there are very, very, few circumstances under which you should need to know
this, even if it were consistently true, and that it's a red herring. It's
an interesting trivia point, maybe, but it frankly doesn't matter, and
encouraging readers to rely on it is foolhardy.

Of course you can sensibly argue that one's complement and sign-
magnitude should be covered. There are often choices which have to be
made, and you have to balance coverage of all the material with
brevity.

It would have been only marginally less terse to write:

On most common desktop systems, ...

and I wouldn't have complained about that.

But it's not an error in the sense that you mean it.

It is an example of a thing in a book purporting to be not only "a reference"
but "the *COMPLETE* reference", which is at best misleading or useless.
It's a good example of the book not being a good choice for learning C.

Anyway, if your argument is that I should write a much more detailed analysis
of the flaws of the book, I guess I can see the argument, but frankly, is
it really worth the effort? There's plenty of material out there to establish
that Schildt produces very bad books about C.

We now have Nilges stating, on the record, that the only reason he's pursuing
this page is that he mistakenly believes that if my page were taken down, he
would be able to get away with vandalizing Wikipedia's entry to remove the
*completely factual and undisputed by anyone but him* statements that
Schildt's books are the subject of "controversy".

Wikipedia isn't claiming that Schildt's books are unambiguously bad, only that
there are many qualified and competent experts who claim that they are very
bad. That claim is undisputed. Nilges has been trying to vandalize the
entry for ages, and has gotten repeatedly banned.

I don't really get your motivation here. You're adding fuel to an already
massively harmful fire which has been disrupting productive and interesting
discussions of real topics for *years*. You're allying yourself with someone
whose favored tactics include threatening legal action against people,
escalating apparently-untrue complaints to try to get people fired, and
otherwise making a nuisance of himself... *even though he is completely
wrong*.

The book is crap. Here, let's play Random Page!

Page 288... Whaddya know" In the 4th edition, if there's an error, it's
too subtle for me. On the other hand, it's purely an enumeration of the
C99 _Pragma() feature and the __VA_ARGS__ macro expansion feature. So
let's look in the 3rd edition.

The header file associated with the I/O functions defined by
ANSI is called STDIO.H.

Okay, that's wrong.

The UNIX-like I/O system is not defined by the ANSI C standard and
is expected to decline in popularity.

Well, the first part is true, but there was a standard at the time covering
that system, and it does not seem to have declined in popularity.

For many C compilers, the header file related to the UNIX-like file
system is called IO.H.

Never heard of such a header, even allowing for the bogus caps. Anyone
know whether it's a DOSism?

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.



-s

 

[jacob navia]

ImpalerCore a écrit :

This is not the kind of attitude that will lead people to want to use
your container library.

Yes, I should stop that container library.

I should stop giving my work for free, contribute to this group and
do my job where I get money for what I do.

You agree that calling me a jerk is good manners, but writing thomson
with lower case is an insult.

Nice for you, I did not expect anything else, from you or heathfield
and all the others.

 

[Seebs]

ImpalerCore a écrit :

Yes, I should stop that container library.

He didn't say that.

I should stop giving my work for free, contribute to this group and
do my job where I get money for what I do.

He didn't say that either.

You agree that calling me a jerk is good manners, but writing thomson
with lower case is an insult.

He didn't say that either.

Nice for you, I did not expect anything else, from you or heathfield
and all the others.

The problem here is not that you're bitter about the treatment you're
experiencing. The problem is that most of the treatment you're experiencing
does not exist in the world external to you. You are experiencing your
own bitterness, not the things people actually say to you.

You make a ton of claims, such as that no one contributes or makes suggestions
about your projects, but people often do, and not all of them are "don't do
that". I've given you several responses where I suggested improvements, or
agreed with one of your design criteria; in those cases, I've been arguing,
not that you shouldn't do a container library, but ways in which I think your
container library can be better. I write those suggestions because it's
quite clear that you are passionate about this, and I am a big fan of trying
to help people do things that they think are important.

But it's pretty frustrating, because even though I've put a fair bit of time
into kibitzing, suggesting things, and trying to articulate things that I
think might be barriers to acceptance that you might need to overcome to get
widespread adoption... All you seem to hear is that I "don't like" it, so
you talk about people attacking you, trying to destroy you, and so on.

Serious question: Do you know whether you might have some kind of serious
depression going on? I have a few friends who are prone to depression, and
the kind of black fog of "everybody's hostile and just wants to destroy me"
stuff you say sounds a whole lot like what depressed people say. If you
haven't looked into that before, I would suggest that you talk to a doctor
about it -- depression is dangerous, potentially lethal, and eminently
treatable.

-s

 

[ImpalerCore]

ImpalerCore a crit :





Yes, I should stop that container library.

I should stop giving my work for free, contribute to this group and
do my job where I get money for what I do.

You agree that calling me a jerk is good manners, but writing thomson
with lower case is an insult.

Nice for you, I did not expect anything else, from you or heathfield
and all the others.

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.