Mail Archives: djgpp/2000/10/16/08:45:16.1
ChuckEasttom wrote:
>
> In article <39EAA40B DOT 31B0CA89 AT eton DOT powernet DOT co DOT uk>,
> Richard Heathfield <binary AT eton DOT powernet DOT co DOT uk> wrote:
> > ChuckEasttom wrote:
> > >
<snip>
> >
> > Schildt is probably the primary reason that so many C programmers
> think
> > main returns void.
> > Schildt is probably the primary reason that so many C programmers
> think
> > fflush(stdin) is a "neat trick".
>
> Whether you or even I like it, that piece of code is a part of the C
> language.
No, it isn't. The behaviour of fflush on input streams is undefined.
>
> > Schildt is probably the primary reason that so many C programmers use
> > gets().
>
> Ditto, whether you or I like it, that piece of code is part of the C
> language.
True, but it can never be used safely. The Internet Worm of 1988
exploited gets()'s inherent weakness for malicious purposes. There's
really no reason to deliberately introduce weaknesses and security holes
into your code. Schildt has a responsibility, as a C populariser, to be
aware of this problem and to guide people away from it. He has failed so
to do.
>
> You seem to object to a lot of code that is part of C and is recognized
> by every single c compiler on the market.
fflush is part of C, but fflush(stdin) is not. gets() is part of C, but
is still objectionable, because it *cannot* be used safely.
<snip>
> >
> > To select a typical example of his handiwork more or less at random,
> > p550 of "C - The Complete Reference" 2nd edition has the following
> code:
> >
> > void enter(void)
> > {
> > char s[256], *p;
> >
> > do {
> > printf("enter appointment %d: ", spos+1);
> > gets(s);
> > if(*s==0) break; /* no entry */
> > p = malloc(strlen(s));
> > if(!p) {
> > printf("out of memory.\n");
> > return;
> > }
> > strcpy(p, s);
> > if(*s) qstore(p);
> > } while(*s);
> > }
> >
> > Now, structured it ain't, but let's not worry too much about that,
> when
> > there's so much else to worry about.
> >
> > Bug 1: no guarantee that the prompt will be displayed before the input
> > function is called.
>
> How would you re write this.
I'd either use a \n on the end of the prompt or, if that were
unacceptable for "aesthetic" reasons, I'd introduce
fflush(stdout);
between the output statement and the input statement.
>
> > Bug 2: use of gets(). Anyone caring to type in 256 non-'\0' characters
> > can cause this program to break.
>
> I agree that much of his sample code is not set up to handle erroneous
> data. I personally attribute this to his simply trying to show the
> programmer a particular technique. Most sample code in most books does
> not cover every single item.
To have used fgets(), with code to handle end-of-data gracefully, would
have taken very few extra keystrokes, and would have been infinitely
more robust. Sample code in C tutorials has a responsibility to be at
least minimally robust.
>
> > Bug 3: the malloc call is getting one byte too few to store the
> string,
> > so the strcpy will cause undefined behaviour.
>
> I agree with you on this one.
>
> > Bug 4: unnecessary test of *s before qstore call.
> > Bug 5: unnecessary test of *s in while loop.
>
> Unnecessary is not necessarily a bug. A bug is a piece of code that
> does not function as planned.
Well, this code certainly doesn't function as planned! Okay, you're
right that I was a bit picky here. Was it not you, though, who said
"Unnecessary code is bad code"? Schildt makes *three* attempts to ensure
that the string is handled safely, and yet all of them fail to ensure
this. But it would have been so easy to get it right.
<snip>
> I am amazed at the number of self professed gurus in comp.lang.c . It
> seems to me that so many people with no publications of their own,
You never did do that Web search, did you?
Anyway, whether I do or do not have publications of my own is irrelevant
to the fact that Schildt's code is all too often erroneous. Now,
mistakes in publications are inevitable, as I know all too well. In
fact, there are mistakes even in K&R. But it is incumbent upon an author
to publish known errors. Dennis Ritchie has published (and maintains, as
has been proved only a week or two ago) an errata list for "The C
Programming Language" on the Web. Where can I find the errata for
Schildt's books? Do you know? And yes, I have looked for them. I drew a
blank.
> no
> advanced degrees, no accomplishements beyond working as a programmer
> for several years..are so ready to jump any any mistake (percieved or
> actual) they see. Hmmmmm I wonder whats up with that?
I don't see anything wrong with drawing attention to error, in the hope
that it will be corrected, or (when that hope fades) at least in the
hope that people will not be misled by it. Furthermore, the sheer number
of Schildt's bugs, ***and his refusal to acknowledge and correct them***
makes them impossible to ignore. Even Knuth has bugs in it; but nobody
rubbishes Knuth, because (a) his contributions to programming are
colossal, and the very few bugs are trivial in comparison, and perhaps
even more importantly (b) he /acknowledges/ his mistakes as they are
pointed out to him, and corrects them in future editions of his books.
If Schildt has an "advanced degree", why does he make so many mistakes,
and (more importantly) why does he fail to acknowledge them so that he
does not unwittingly mislead people? And why should he be immune to
criticism? Surely someone with an advanced degree should be under /more/
scrutiny than someone who does not?
And if he doesn't have an advanced degree, your argument loses what
little force it might otherwise have had.
If you're going to appeal to authority (and saying I have no right to
criticise unless I have a degree or a publication record is as close to
an appeal to authority as makes no odds), then let it be an appeal to
*appropriate* authority. In this case, the appropriate authority is the
ISO C Standard, which defines the language. If Schildt claims that his
books[1] cover ANSI C (and he generally does claim this), those books
should be judged against the ANSI C Standard (which is, of course, the
same as the ISO C Standard). His books[1] have been measured against
that standard, and found wanting.
[1 - Specifically, "The Annotated ANSI C Standard" and "C - The Complete
Reference"; I've read Clive Feather's review of the former, and read the
latter myself. Whilst I don't make any statements of fact one way or the
other about any other C books he's written, I'm not hopeful that they're
any better.]
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
- Raw text -