Message-ID: <39EAF73E.ECA52E1A@antlimited.com> Date: Mon, 16 Oct 2000 13:40:30 +0100 From: Richard Heathfield X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.comp.lang.learn.c-c++,comp.os.msdos.djgpp,comp.programming Subject: Re: Undertaking a programming journey References: <8scg36$gsm$1 AT nnrp1 DOT deja DOT com> <39E9CF07 DOT 785C0C0F AT eton DOT powernet DOT co DOT uk> <8scls9$kth$1 AT nnrp1 DOT deja DOT com> <39E9FAD5 DOT DE1FDAE4 AT eton DOT powernet DOT co DOT uk> <8sdrub$h7u$1 AT nnrp1 DOT deja DOT com> <39EAA40B DOT 31B0CA89 AT eton DOT powernet DOT co DOT uk> <8seoli$65v$1 AT nnrp1 DOT deja DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: fb-ext.ant.co.uk X-Trace: 16 Oct 2000 13:36:18 GMT, fb-ext.ant.co.uk Lines: 176 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com ChuckEasttom wrote: > > In article <39EAA40B DOT 31B0CA89 AT eton DOT powernet DOT co DOT uk>, > Richard Heathfield wrote: > > ChuckEasttom wrote: > > > > > > > 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. > > > > 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. > 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