Mail Archives: djgpp/2000/10/16/07:45:33
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 exposé URLs>
> > >
> >
> > Something you seem to miss is that the beauty and power of C is the
> > fact that it lends itself to a variety of programming styles. I
> > personally liked Schildts books. I have only read three of them but
> > the ones I read I liked. They where not perfect, but they where
good.
> > Appearantly a lot of other people do, since they sell so well.
>
> Yes, they do sell well, don't they? So do horoscopes.
>
> 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.
> 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.
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.
> Schildt is probably the primary reason that so many C programmers
think
> exit(1) is portable.
no comment on this one.
> Schildt is probably the primary reason that so many C programmers
don't
> understand ISO namespace.
>
> 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.
> 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.
> 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.
>
> 5 bugs in 17 lines (including whitespace and curly braces). One bug
> every 3.4 lines, in a book which, despite its name, intends to be a
> tutorial. Admittedly it's a small sample. Nevertheless, I once made
the
> mistake of claiming, in comp.lang.c, that there was bound to be at
least
> one page in the book that didn't have a single mistake on it anywhere,
> and Dann Corbit challenged me to produce such a page. I couldn't.
>
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, 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?
> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> 66 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (31
> to go)
>
--
http://www.geocities.com/~chuckeasttom/
Sent via Deja.com http://www.deja.com/
Before you buy.
- Raw text -