wtwolfe@hubcap.clemson.edu (Bill Wolfe) (02/26/90)
Following are some prime examples of why the C community is thought
of by many as having an unprofessional and irresponsible attitude
toward software reliability:
DAB(!1) There is a mysterious bug causing occasional core dumps...
...just send mail to the author.
FILE(1) It often makes mistakes.
JOBS(3J) There is no excuse for the "getwd" routine to be in the
jobs library. There is even less reason for this routine
not to have been documented by the author(s) at Berkeley.
PARSEDATE(3) The grammar is incomplete and always will be.
PUTC(3) Errors can occur long after the call to 'putc'.
SCANF(3S) The success of literal matches and suppressed
assignments is not directly determinable.
SIN(3M) The value of 'tan' for arguments greater than about 2**31
is garbage.
CTAGS(1) ...if you have two Pascal procedures in different blocks
with the same name, you lose.
EMACS(1) Not bloody likely.
TC(1) The aspect ratio option is unbelievable.
UNITS(1) Don't base your financial plans on the currency conversions.
BBEMACS(1) I tinker too much, so occasionally I mess up and it
don't work no good. But then I fix it, hooray.
When examples such as these are combined with the existence of so many
blatantly unsafe constructs within the C language, and the fact that C
software seems to erode public confidence in software reliability on a
regular basis (Nationwide Computer Network Infected By Worm; National
Telecommunications System Crashes), it would seem appropriate to ask:
When is the C community going to clean up its act???
It appears that there is a real need to publicize software engineering
concepts throughout the C community, both directly through software
engineering education and indirectly through a redesign of the C language
to provide greater support for the software engineering process. If
these steps are taken, it will hopefully be possible to avoid any further
destruction of the public's confidence in software reliability. If not,
government regulation of the field will probably soon become inevitable.
Bill Wolfe, wtwolfe@hubcap.clemson.edu
john@newave.UUCP (John A. Weeks III) (02/26/90)
In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: > [ ... List of bugs in software that Mr Wolfe is probably using for FREE ] Bill, I take great exception to your accusing me of being unprofessional. I can write really good or really bad code equally well. The difference between the two is the amount of time that I am allowed, and how much I am being paid. > When examples such as these are combined with the existence of so many > blatantly unsafe constructs within the C language, and the fact that C ^^^^^^ read "useful" > software seems to erode public confidence in software reliability on a > regular basis (Nationwide Computer Network Infected By Worm; National > Telecommunications System Crashes), ... Would you feel better if the networking code was written in BASIC? I bet someone would have to modify BASIC to allow exponential format for the line numbers. Didn't Church prove that you can develop an equally poor implementation of a problem in any language? > ... it would seem appropriate to ask: > When is the C community going to clean up its act??? The big issue is economics. You can have the current nationwide network for X dollars, or a "totally secure" network for many times more than X. Please think about three facts: 1. Totally secure is not possible (nor is totally reliable) 2. Extra levels of security will probably reduce overall productivity at all levels, so you can multiply X a few more times. 3. If the cost were much higher, would it exist at all? If my managers doubled our development budget, we might improve the quality of our already excellent products. But more likely, management would rather have us turn out twice as many products. > It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education ... The solution to an economic problem is an economic solution: pay good programmers well, pay poor programmers poorly. As long as poor programmers are in heavy demand, poor code is going to be written. The economics will dictate the accepted level of education (my theory on why MBA's are so popular). If you wish to construct a top-notch product, hire top-notch programmers with a proven track record, and pay them well. If you hire an overworked grad student for $3.65 an hour, you may find that your employee might not really care about doing a good job. > ... and indirectly through a redesign of the C language > to provide greater support for the software engineering process. Isn't one version of ADA enough? > If not, government regulation of the field will probably soon become > inevitable. Yea, right. Like government regulations keep seedy people out of the legal profession. And MD's never let drinking problems affect their work. I used to work in an industry that required all workers to have federal permits. There were some very good and some very poor radio technicians, but most were in the average category. Now that the FCC no longer requires federal permits for radio workers (only for radar and for federally regulated installations...like air traffic control), the industry still has the same mix of people. Some good, some bad, but most are average. The bottom line? If you have a problem with a program, do not blame the programmer. Aim the questions at his or her management. Management is ultimatly responsible for all software projects, whether it be a Microsoft sized company or a professor with 1 part-time student worker. (I exempt the wonderful software that is posted by USENET people from this discussion and from my "bottom line". Freeware is in a class above this discussion.) -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!bungia!wd0gol!newave!john ===============================================================================
ok@goanna.oz.au (Richard O'keefe) (02/26/90)
I'm fond of saying "the more I like C, the better I like Ada", but I really couldn't let Bill Wolfe's message pass unchallenged. In article <8147@hubcap.clemson.edu>, wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: > DAB(!1) There is a mysterious bug causing occasional core dumps... > ...just send mail to the author. What is dab? How do you know it is written in C? > FILE(1) It often makes mistakes. 'file' is a UNIX command which tries to guess what kind of information a file contains. The UNIX file system does not have store 'type' information with files, so it CAN only guess. (One file system I have used tagged files as PascalSymbol, AplWorkSpace, AlgolCode, and so on, for over 200 different types. The Macintosh file system does much the same. Unix _doesn't_.) Current versions of 'file' are controlled by an /etc/magic file, but you can't tell them about new programming languages (if anyone has a version of 'file' which looks for keywords in /usr/lib/vgrindefs, let me know). But the classification task is in principle impossible to get precisely right: is (+ 1 1) (a) Lisp, (b) Scheme, (c) data for a Lisp or Scheme program, (d) something else? This has _nothing_ to do with the language that 'file' is written in. > JOBS(3J) There is no excuse for the "getwd" routine to be in the > jobs library. There is even less reason for this routine > not to have been documented by the author(s) at Berkeley. That was a temporary hack in 4.1BSD. There is no jobs library in 4.2BSD or 4.3BSD and getwd() _is_ documented. Again, where is the evidence that this has something to do with C? (I've seen one OS written in Pascal and another in Fortran, and have _no_ reason to think them better.) > PARSEDATE(3) The grammar is incomplete and always will be. This is another problem which is unsolvable in principle. What is provided is a useful approximation. The incompleteness has nothing to do with C as such. (The fact that parsedate was distributed free over the net _does_ have something to do with C.) > PUTC(3) Errors can occur long after the call to 'putc'. This _is_ a property of the programming language C, now that the stdio library is a standardised part of the language. There are two parts to the problem: -- most implementations of putc() don't check that the file is in output mode at the time of call; _that_ I cannot excuse because it is easy to implement stdio so that it _does_ check then and there (the trick is to use *two* counters: "how much input left in buffer" and "how much space left for output in buffer"). -- even if the file is in output mode, _physical_ I/O errors are not reported immediately. It is worth noting that the second point ALSO applies to UNIX implementations of Ada. It must, because it is a UNIX problem, not a C problem. In fact, because of the way UNIX buffers disc i/o, a physical error may not be detected until after the file is CLOSED, which is a right pain. Some recent UNIX systems do provide a system call which can be used to prevent the problem; I am told that it is costly. I imagine that this problem does not occur under MS-DOS. > SCANF(3S) The success of literal matches and suppressed > assignments is not directly determinable. Scanf() is one of my pet hates. It is surprisingly slow as well. > SIN(3M) The value of 'tan' for arguments greater than about 2**31 > is garbage. I am indebted to Bill Wolfe for pointing this one out; I usually go by the SVID (which is quite explicit that for partial loss of significance as much as possible of the result must be returned and that for total loss of significance a message is printed and 0 returned; in either case errno is set to ERANGE), or by a draft of the ANSI C standard (which does not license anything like this), or by SunOS documentation. The Encore manual page does contain this message, which apparently pertains to some 4.2BSD implementations, and it had never occurred to me that it might. It's worth pointing out that there is nothing in Ada to prohibit an Ada implementation doing this too: tan() is _not_ an official part of Ada. It would be worth checking what Ada systems do on 4.2BSD... Yes, I know about the Ada Numerics Working Group. I am really enthusiastic about their definition of the trig functions, and that definitely really does give you something you can _trust_. I would be _very_ happy for that to be cited in an appendix to the C rationale as a worthy guide for C implementors (too late to affect the standard). By the way, is the version of tan() in question written in C, or is it written in assembler? It makes a difference to the argument! > CTAGS(1) ...if you have two Pascal procedures in different blocks > with the same name, you lose. The whole idea behind a 'tags' file is that there is only one occurrence of any given name as a routine name in the given cluster of files. This specific problem is not a problem with 'ctags' as such, but a consequence of the fact that the data structure it is required to construct simply cannot express this situation. There _are_ serious problems with ctags. In particular, because it operates on the raw text instead of preprocessing and parsing it, the following example #if 0 #define foo(x,y) (((x)+(y))/2) #else double foo(x, y) ... #endif will be misunderstood: the first occurrence of 'foo' will be mistaken for the definition and the real definition will be reported as an error. Another problem is that 'ctags' and 'file' use different heuristics for guessing the language of a file. The fundamental problem is that 'ctags' is trying to do something which is not in principle doable, thanks to the existence of the preprocessor. > EMACS(1) Not bloody likely. This tells us nothing about C. (Particularly when you consider that Emacs variants have been written in Teco, Lisp, PL/I, Pop, and C, to name but a few.) > TC(1) The aspect ratio option is unbelievable. What _is_ tc? We haven't it here, and it's not in the SVID. How do you know it is in C? > UNITS(1) Don't base your financial plans on the currency conversions. This has nothing to do with C. It's a straightforward consequence of the fact that the 'money' part of /usr/lib/units was fixed at 16-June-1980. The currency conversions are just fine for that day. Since the 'units' program is driven by a readable source file, if you want current figures, plug 'em in. The issue here is not a LANGUAGE issue but a DESIGN issue. Shall we a) not provide any currency conversion information at all? b) provide currency conversion correct at a particular date, but with no _automatic_ means of updating it? c) provide currency conversion updated daily? From what source? Exactly the same choices would confront an Ada user, and exactly the same considerations (how can we get at currency figures _portably_) might lead to the same choice. (Since the introduction of the 'news' software; it would make sense to have a comp.currency newsgroup with daily updates...) > BBEMACS(1) I tinker too much, so occasionally I mess up and it > don't work no good. But then I fix it, hooray. This is pretty shocking, but what has it got to do with C? The very *worst* publicly available software I have ever seen was written in Pascal. > When is the C community going to clean up its act??? What C community? Wolfe cited some utilities & libraries from 4.2BSD, does he mean Berkeley? He cited some programs I've never heard of (dab, tc, bbemacs), does he mean their authors? He cited some functions from the C library, most of which HAVE been cleaned up. The really important thing is that Wolfe has failed to show (and didn't even _try_ to show) that there was any causal connection between the defects of these programs and the use of C. Remember Sturgeon's Law: 90% of _everything_ is crud. I repeat, the more I use C, the better I like Ada. (And Eiffel.) (No, _especially_ Eiffel.) But Wolfe needs a better argument. > It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education I agree 100% with this, except that I'm not convinced that there IS a single "C community" whose act needs to be cleaned up. What we really want is a large number of low-cost (< US$300, say) Ada compilers scattered around enough so that people start contributing Ada sources to the net. Then we'll get a chance to see how much of a difference the language makes. In the mean time, we have to make do with what we've got.
dmr@alice.UUCP (Dennis Ritchie) (02/26/90)
Wolfe, I gather, intends to construct a case against C by grepping for titillating phrases in the BUGS section of his manual. Rather than decry the C community's derelictions in not maintaining a direct line to the international money markets (so as to keep the monetary conversion coefficients of the units program up to date, and thereby salvage our reputation in the software engineering biz), I think it would be more appropriate to discuss Wolfe's (wtwolfe@hubcap.clemson.edu) complicity in recent and past Clemson football scandals. Did he have any role in the jock dormitory affair? What was his relationship with Danny Ford? These questions seem approximately as relevant as the ones Wolfe raises. Dennis
btrue@emdeng.Dayton.NCR.COM (Barry.True) (02/26/90)
In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > > [ Comments about certain commands in C and their 'pitfalls' deleted] > > When examples such as these are combined with the existence of so many > blatantly unsafe constructs within the C language, and the fact that C ^^^^^^^^^^^^^^^^ > software seems to erode public confidence in software reliability on a > regular basis (Nationwide Computer Network Infected By Worm; National > Telecommunications System Crashes), it would seem appropriate to ask: > > When is the C community going to clean up its act??? > Blatantly unsafe???? How doe you define BLATANTLY? And unsafe for whom? The inexperienced C programmer? I would hazard to guess that there are many constructs in many languages that would be confusiong to an inexperienced programmer of that language until they learned to use them properly. These constructs could be termed unsafe to use by that programmer until he/she learned enough about the language to know in what context they could be use "safely" and efficiently. To labal a construct as blatantly unsafe, however, is to say that that construct is unsafe for use by ALL programmers in ANY environment and in ANY usage WHATSOEVER. I think that this is a bit much to say for any programming language construct. > It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. If > these steps are taken, it will hopefully be possible to avoid any further > destruction of the public's confidence in software reliability. If not, > government regulation of the field will probably soon become inevitable. > You don't redesign the language to teach a programmer how to use it. You have to develop better methods in training a programmer in the proper use of the language. To single out the C community (or any other programming community) as needing to adhere to better software engineering concepts in exclusion of any other programming community is hogwash. I have been programming in C/UNIX for ten years. In that time I have seen my share of bad programming practices, none the least of which was poor quality training. I have worked in shops where the impression of C was that any competent programmer could learn how to use it effectively by taking a one-week class. This was a COBOL/CICS shop, by the way. It appears from this that it is not the C community that needs to developm better software engineering concepts, it is the software community in general. Show me a COBOL programmer that can learn enough about all implementations of C in one week to be able to "safely" and efficiently program in the language in EVERY circumstance and I will personally doff my hat to the next generation of super-programmer..8-)!!!
jharkins@sagpd1.UUCP (Jim Harkins) (02/27/90)
So out of several thousands of commands and programs, some quite complex (like emacs) you found a handful of bug reports and use this to condem C? It seems to me like you are stumbling over one of the philosophical questions of programming, to wit: If there is a known bug to you tell the customers about it or hope they never see it? If you tell them about the bug then they may get cold pricklies about your software, but then again they may admire your forthrightness, especially if you can prevent them from losing hours of work by tripping over the bug for themselves. If you don't tell them about the bug (this seems to be the way 90% of companies operate) then chances are most people won't stumble over all the bugs so they won't know how bad the software really is. And don't tell me that software shouldn't be shipped without bugs, this is the real world. -- jim jharkins@sagpd1 "I've found by and large that when the flu gets you, the best thing to do (other than go to bed, which is boring) is to go conquer something." -Jerry Pournelle
henry@utzoo.uucp (Henry Spencer) (02/27/90)
In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: Bill, aren't you confusing C with Unix? Some of the software you mention is not even written in C on most Unixes. Actually, I think you're confusing C with the Unix from your particular vendor, since some of the programs you mention are things I've never heard of that don't appear in any of the quasi-standard sources. > FILE(1) It often makes mistakes. Necessarily so; there is no way to be certain of the type of a file in an operating system which doesn't tag files with types, so file(1) has to guess. This is documented. > PUTC(3) Errors can occur long after the call to 'putc'. This is a problem with any buffered i/o package in any language/system. Delaying i/o in hopes of doing it in larger units inherently delays reports of i/o errors. > SCANF(3S) The success of literal matches and suppressed > assignments is not directly determinable. Yup, a slightly bad design which is difficult to fix because of problems of backward compatibility. Scanf is, in any case, unsuited to heavy-duty input parsing; it's strictly for quick-and-dirty lightweight stuff. > SIN(3M) The value of 'tan' for arguments greater than about 2**31 > is garbage. Complain to your vendor -- this is an implementation problem on your particular machine, although range reduction on trig functions is in general a tricky problem. As near as I can tell with a quick test, the one here gets it right. Note that the C standard forbids such misbehavior; your vendor has blown it. Long odds his Fortran TAN() function is just as broken. > UNITS(1) Don't base your financial plans on the currency conversions. Almost any source of currency data which isn't on-line with world money markets will carry the same warning... or should. (Actually, this is a more general point: the things you point to are at least *documented*, which is often not the case for bug lists in other systems.) > When examples such as these are combined with the existence of so many > blatantly unsafe constructs within the C language, and the fact that C > software seems to erode public confidence in software reliability on a > regular basis ... In a way that Cobol and Fortran programs, not to mention assembler programs, somehow don't? If you read comp.risks, you will find that such problems are by no means confined to C. There are incompetent programmers using just about every language you care to name. > It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. If > these steps are taken, it will hopefully be possible to avoid any further > destruction of the public's confidence in software reliability. If not, > government regulation of the field will probably soon become inevitable. The above paragraph, of course, is true with a global substitution of any programming language -- Fortran, Cobol, assembler, Ada, you name it -- for C, and merely reflects the gross incompetence of many people who claim to be programmers. "The most failure-prone part of your car is the nut behind the wheel." -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
woods@robohack.UUCP (Greg A. Woods) (02/27/90)
In article <2910@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes: > I'm fond of saying "the more I like C, the better I like Ada", > but I really couldn't let Bill Wolfe's message pass unchallenged. I almost hit the `F'lame key too, but held off at least long enough to read Richard's message. I was particularly pissed off by the way Mr. Wolfe cited the particlular set of "BUGS" excerpts without contextual reference. Just one quibble with the rebuttal: > In article <8147@hubcap.clemson.edu>, wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > > CTAGS(1) ...if you have two Pascal procedures in different blocks > > with the same name, you lose. > > [....] > The fundamental problem is that 'ctags' is trying to do something which > is not in principle doable, thanks to the existence of the preprocessor. But again, nothing here relates directly to C. Ctags could be written in anything, even COBOL. BTW, what does the preprocessor have to do with "ctags" for Pascal? As for Software Engineering: > > It appears that there is a real need to publicize software engineering > > concepts throughout the C community, both directly through software > > engineering education [....] > > I agree 100% with this, except that I'm not convinced that there IS a > single "C community" whose act needs to be cleaned up. I also agree 100%, except I would insist upon the replacement of "C community" with "programming community". > What we really want is a large number of low-cost (< US$300, say) > Ada compilers scattered around enough so that people start contributing > Ada sources to the net. Then we'll get a chance to see how much of a > difference the language makes. In the mean time, we have to make do > with what we've got. I'd suggest it'll take a free and easily portable compiler of some modern language, not just a low-cost one. I doubt ADA is the best such language either. I've been trying to learn more about Modula-3, but getting a compiler has not proven easy. C++ is good, but it still gives you more rope than you need. I don't really like Eiffel, nor Objective-C. Smalltalk-80 is still my favorite language next to C. I believe I learned the most about programming from lisp. Perhaps Scheme or lisp are the best teaching languages. I have a friend who swears APL is one of the best languages. Until software engineering is taught with as much care and vigor as medicine (or law?), and until we can judge only software created by the resulting engineers, we will not be without examples such as those cited by Mr. Wolfe. C is certainly not to blame for the lack of quality and reliability. Unix cannot be blamed either. Unix may have fostered many poor examples of quality and reliability (perhaps because of its early introduction into the academic community). However, I would say it has also given birth to many more good examples than any other single environment. -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
peter@ficc.uu.net (Peter da Silva) (02/27/90)
If you want to talk about blatantly unsafe constructs, how about ADA's use of
rendezvous as the primary (maybe only) message passing construct? The MINIX
operating system is written in C, but the biggest source of subtle bugs in the
system (from my observation of the discussions in comp.lang.minix) is the use
of rendezvous. I understand that the DoD has given up on using ADA's tasking
and switched to a hosted environment on top of VRTX partly because of this.
Then again there's the use of operator overloading to sort-of-implement object
oriented programming. "So what does `A+B' mean in this context?"
I suspect that a major reason that C bugs and Fortran bugs and Cobol bugs are
better known than ADA bugs and PL/I bugs is simply because these languages have
seen more use. A new broom sweeps pretty clean...
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'martin@mwtech.UUCP (Martin Weitzel) (02/27/90)
In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: > [list of citations deleted] A language with no bugs documented does not necessarily have none. A language that is not critized for deficiencies, is suspicious not to be in wide use. Two years ago I decided to start a project with INFORMIX 4GL. From time to time my work went into isolating contained Bugs. (Because I just was learning myself, it often took some time to trim down the problem to the smallest failing case, then to detect that it was not my fault and finally finding some workaround.) Of course, the bugs were never mentioned in any manuals and might give some naive user the impression, that the language was "better" than C. I think within three months of work I spent at least three weeks with isolating bugs and looking for workarounds! The next thing I missed in this language were constants: You could not do other than writing them explicitly twice, if you defined an array and had to write a loop to process the entries later. I think, a language that calls itself "fourth generation" should have learned from 3rd generation languages! I had to circumvent this by writing my own preprocessor (with UNIX m4). The support for structuring a program into multiple reusable moduls, was far below that of C. Language constructs seemed somewhat arbitrary defined. Eg in C, if there is a 'int'-value required, there are only two situations: It must be a compile-time expression or it can any expression evaluated on run-time, ranging from a constant to a complicated expression with indexed array elements or whatever. Not so in 4GL: Sometimes a constant and a variable was allowed, sometimes only a constant or only a variable (yes, there were situations were a *value* which was used unchanged had to be a from a variable, not a constant.) Sometimes expressions were allowed, but on other occasions theese should not have any array-elements embedded. Again: this language was called a *fourth* generation language. Finally, the project was unsuccesfull on the 80286, because of its limited (segmented) adress space and the tendency of a 4GL-Program to grow really large in a serious programm, that had to do a little more than the demo data base that came with 4GL. I allways lived in the fear, that I could reach the limits of some resource, because for the fewest of them any "minimum guarantees" were given! Finally, the 80286 segmentation and the linker came into way. (With C I could be sure, that anything as complex as a compiler and the UNIX-Kernel can be writte in this language.) > > It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. If A C programmer needs more education, training and knowledge as the average BASIC programmer - but not because the language is worse in design than others, but because more serious work is done in C. I don't believe, that any other language with the same broad spectrum of uses as C, can be designed to be used with less effort or education. You may take this as my vote, that we need more specialized languages for certain problem domains, but I think there is few room for a 'better C'. At least for INFORMIX 4GL (in the state of design from 1988) I can say, that a newer language which promissed that you "describe the solution, not the way to get to the solution" was worse than C in any aspect, if you tried to use it for non-trivial projects! (BTW: ESQL/C is much better in this respect, but leads the not so well educated programmers into all traps and pitfalls you find in C.) > these steps are taken, it will hopefully be possible to avoid any further > destruction of the public's confidence in software reliability. If not, > government regulation of the field will probably soon become inevitable. What kind of regulation are you thinking of? (Don't know, if I should put a Smiley here or if you forgot one ....) > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu > -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) (02/28/90)
In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: The following comments, taken out of context, such as they are, prove little. And, when put back into context prove even less. Your comment about cavalier attitude to programming is not something that is unique to C. It should be pointed out that any of these programs could have been written in Pascal, or Basic, or Assembler and still have the same problems and/or manifestations. If you are talking about the writing style of the comments you present, as opposed to the actual content of the messages, then you are attacking a different thing: namely that the quality of most manuals is awful. To site a few contraditions to your messages: > DAB(!1) There is a mysterious bug causing occasional core dumps... > ...just send mail to the author. Agreed, bad style, but some bugs are extremely hard to detect. I am not sure what DAB is so I can't comment on this more. > FILE(1) It often makes mistakes. This is not a programming issue, but rather a problem with being able to deterministicly tell what any type of file is. This is very difficult if you do not have an attribute oriented filesystem since source code will look like English text and Vice Versa. > JOBS(3J) There is no excuse for the "getwd" routine to be in the > jobs library. There is even less reason for this routine > not to have been documented by the author(s) at Berkeley. The author of the manual page may have a point, but may not be able to rectify the problem due to historical significance. Better to point it out so that future coders could rectify the problem given the chance. > PARSEDATE(3) The grammar is incomplete and always will be. The grammar for dates is notoriously ambiguous. Everybody has a favorite way of writing "the twentieth day of the Fifth month of 1990". Some say 5-20-90, some say 20-5-90, some say 90-20-5, some say 20-May-90, etc. This is another one of those potentially non-deterministic type things, primarily due to the fact that 2-5-90 can be interpretted in two different ways. > PUTC(3) Errors can occur long after the call to 'putc'. Not a problem of the implementation, but a function of the way that Unix (and other systems) do file buffering. > SCANF(3S) The success of literal matches and suppressed > assignments is not directly determinable. If you know scanf, then you know that this is true. Basically you ask for the computer to pattern match something for you, but tell it not to let you know what it matched, if anything. Would be tough (impossible?) to fix given the current interface. > CTAGS(1) ...if you have two Pascal procedures in different blocks > with the same name, you lose. If you build a single key data base with two identical keys and then attempt to access the database using that key... > EMACS(1) Not bloody likely. Huh? > TC(1) The aspect ratio option is unbelievable. > > UNITS(1) Don't base your financial plans on the currency conversions. Currency conversions in Units are meant to be rough gueses. Since units can't go query the NYSE to get the current rates, what do you want it to do? > BBEMACS(1) I tinker too much, so occasionally I mess up and it > don't work no good. But then I fix it, hooray. Sounds like and honest programmer. > When examples such as these are combined with the existence of so many > blatantly unsafe constructs within the C language, and the fact that C > software seems to erode public confidence in software reliability on a > regular basis (Nationwide Computer Network Infected By Worm; National > Telecommunications System Crashes), it would seem appropriate to ask: Worms and viruses and hackers and system crashes and unreliable software and poor programming and bad software design and, and, and, all existed long before C was even invented and will persist thoughout time. Again, I would like to point out that the Worm could have been written in Assembly, Pascal, etc. C software does nothing to erode public confidence. Poorly crafted software erodes public confidence. There are some pretty attrocious programs in ADA, PASCAL, MODULA-2. You know, all those languages that are not supposed to allow you to write bad code. Sorry, but they all have bugs too. > When is the C community going to clean up its act??? When are the Cobol programmers of the world going to stop bashing on C and start writing the banking software correctly so that I don't get notices from the bank saying that I am roughly 1.5 Million dollars overdrawn? When are they going to fix code so that programs don't abend causing 4.5 Million dollars to be misplaced? Both of these things happend. One to me (the first), the other I helped track down at the Federal Reserve Bank. Golly, maybe Programmers make the errors not the programming language. You think? Nah... >> It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. If > these steps are taken, it will hopefully be possible to avoid any further > destruction of the public's confidence in software reliability. If not, > government regulation of the field will probably soon become > inevitable. Sorry pal. Start by teaching all those cobol hacks to quit sending letters demanding payment of $0.00 dollars, and make sure that the design of assembly language, lisp and fortran are also all added to the list of languages which need to be redesigned to provide greater support of the software engineering process. Then make common tools to support such effort for all the languages, rather then the 35,000 or so tools that exist today, some of which are a lot more buggy that the phone system ever was... Then force all code to be mathematically tested for accuracy. But tell you what, since all of the rest of us programmers obvously can't write software worth a damn, you better start working on this stuff right away: you got a lot of code to write... -- Mark H. Colburn If you don't make money off of it, Open Systems Architects, Inc. it had better be either a religious mark@Minnetech.MN.ORG experience or a hobby. - Lance Cooper
shurr@cbnews.ATT.COM (Larry A. Shurr) (02/28/90)
In article <10529@alice.UUCP> dmr@alice.UUCP (Dennis Ritchie) writes: >Wolfe, I gather, intends to construct a case against C by grepping >for titillating phrases in the BUGS section of his manual. Hmmm... Perhaps Wolfe is right, the C community (whatever that is) should clean up its act. Let's clean up those manuals by removing those pesky "BUGS" sections and rewrite them, liberally using phrases such as "error- free," "advanced software engineering features," and the like. Yeh. That's the ticket. If only the C community would clean up its act, then there would be no more problems. The world's ills are caused by C programmers. After all, everyone knows that the No. 7 signalling network would not have failed on M.L.K. day if the software had been written in (pick one) Pascal, Modula-2, Eiffel, etc... regards, Larry Hi Randy! -- Signed: Larry A. Shurr (cbnmva!las@att.ATT.COM or att!cbnmva!las) Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave (With apologies to the real thing. The above represents my views only.) (You may now R'eply. Forwarding from cbnews to my mail address now works!!!)
tneff@bfmny0.UU.NET (Tom Neff) (02/28/90)
I think what Bill Wolfe is getting at is this: C and UNIX derive from a milieu where admitting fallibility is not a sin because the "consumers" are programmers, whose competence, understanding and goodwill are assumed; and where explaining bugs up front is considered a plus, because it saves programmer time later on. By contrast, "big computer company" tradition emphasizes the *appearance* of infallibility -- never admit bugs up front because your competition will eat your lunch. Instead, pour money into glossy docs that paint your product as the ultimate in completeness and perfection, *regardless* of what a bug-filled mess it really is. Handle the messy end only after the check clears. :-) What he appears to be saying is that if C and UNIX want to beat IBM at its own game, to win in the marketplace despite programmer curses and muttering, they will have to drop the embarrassing candor and get a haircut. This might even be true except the horse is out of the barn. C and UNIX have *already* been adopted by all the big computer companies, who are diligently working to produce infallible-sounding derivatives with gleaming three-color docs. So who's left? Has Bill been reading the Berkeley manuals and wishing they'd go corporate too? Dream on; they have no motivation.
aperez@cvbnet.UUCP (Arturo Perez x6739) (03/01/90)
From article <8147@hubcap.clemson.edu>, by wtwolfe@hubcap.clemson.edu (Bill Wolfe): > > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: > .... examples deleted .... > > When examples such as these are combined with the existence of so many > blatantly unsafe constructs within the C language, and the fact that C > software seems to erode public confidence in software reliability on a > regular basis (Nationwide Computer Network Infected By Worm; National > Telecommunications System Crashes), it would seem appropriate to ask: I'm frankly offended by the attitude displayed here. I admit that C is not the safest language to code in; it is, after all, just an abstract kind of assembly language. But if you don't like it, don't use it. There are "safer" languages to use, e.g. lisp, pascal, cobol. But what offends me are these assumptions that 1) C is responsible for the bad reputation software has. 2) We need a C gestapo to enforce good coding practice. 3) You can indict the whole C user community because of a few "unreliable" applications. All of the above assumptions are false. Software has a bad reputation stemming from the days when IBM was writing the OS for the 360, sometime in the 1960's. And it hasn't gotten any better with Companies (not Individuals) who make rash announcements of their products and fail to deliver; usually due to unspecified "software problems." Not all of these companies use C; I doubt that the majority do. I know that many engineering companies still use Fortran. Who is going to be the Gestapo? I personally don't know anyone who would want the job or be any good at it. And, finally, since when can you indict a whole community based on the actions of a few individuals? Sounds like an "ism" to me. What's the ratio of "well written" applications to "poorly written" applications? If it's not damn close to 0% then I think you're way offbase. > > When is the C community going to clean up its act??? When are "software engineers" going to clean up their acts? I have on my wall a list of excuses for DELIVERING poorly written, inadequately debugged applications. Why does these applications get released? Because MANAGERS decide what the deadlines are with little input from the engineers and release the software based on criteria other than engineering considerations. The number one reason (in my experience) for "bad" software is lack of time and that lack of time is imposed from above. There are only so many 70 hour weeks you can put in. > > It appears that there is a real need to publicize software engineering > concepts throughout the C community, both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. If > these steps are taken, it will hopefully be possible to avoid any further > destruction of the public's confidence in software reliability. If not, > government regulation of the field will probably soon become inevitable. I don't believe that your efforts at education should be limited to "people who write in C." The problem you've very poorly addressed here is much more pandemic than just being "people who write in C." > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu > Arturo Perez ComputerVision, a division of Prime aperez@cvbnet.prime.com Too much information, like a bullet through my brain -- The Police
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/01/90)
In article <60@newave.UUCP> john@newave.mn.org (John A. Weeks III) writes: >The big issue is economics. You can have the current nationwide >network for X dollars, or a "totally secure" network for many times >more than X. Please think about three facts: One might hypothesize that better, perhaps radically different, technologies and methods would make possible the construction of large software systems - such as those in defense and telecommunications - that are *simultaneously* more robust, much more flexible, and much less expensive to build. But would conservative customers such as the Department of Defense and the Bell operating companies be willing to purchase such "unorthodox" systems? And are conservative vendors such as General Dynamics and AT&T willing to make the large investments such new technologies and methods might require, simply on the *hope* that customer skittishness can be overcome? Remember also that any new technology or method faces vehement opposition: foremost from all those who personally benefit from the current practice, secondarily from those who are emotionally attached to the current practice, and tertiarily (!) from those who simply have no genuine desire to learn anything new. Industries with a vigorous free market have learned to overcome this inertia; but defense and telecommunications are oligopolies (only a handful of full-scale vendors) and nearly monopsonies (a single buyer), and so have not. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/01/90)
[This is a repost, with some correction, of comments that, I think, didn't make it off our news machine.] In article <60@newave.UUCP> john@newave.mn.org (John A. Weeks III) writes: >The big issue is economics. You can have the current nationwide >network for X dollars, or a "totally secure" network for many times >more than X. Please think about three facts: One might hypothesize that better, perhaps radically different, technologies and methods would make possible the construction of large, complex software systems - such as those in defense and telecommunications - that are *simultaneously* more robust, much more flexible, and much less expensive to build. But would conservative customers such as the Department of Defense and the Bell operating companies be willing to purchase such "unorthodox" systems? And are conservative vendors such as General Dynamics and AT&T willing to build such systems on the mere *hope* that customer skittishness can be overcome? Remember also that any new technology or method faces vehement opposition: foremost from all those who personally benefit from the current practice, secondarily from those who are emotionally attached to the current practice, and tertiarily (!) from those who simply have no genuine desire to learn anything new. All told, the barriers are formidable. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
tanner@cdis-1.UUCP (Dr. T. Andrews) (03/01/90)
) Following are ... prime examples of why the C community is thought
) of by many as having an unprofessional and irresponsible attitude
) toward software reliability: [ examples of "bugs" from "man" pages ]
On the other hand, I see this practice as commendable honesty.
Programs have bugs. You know that, I know that, Mr. Wolfe knows
that.
Some of the things cited aren't amenable to change: do you really
expect the currency conversion tables for units(1) to update
themselves every morning from the currency tables in the paper?
That people will
(a) admit that there are bugs,
(b) identify them
(c) solicit assistance in tracking them down
seems to me to be an example of an attitude toward reliability which
should spread. Compare this to the attitude of the shrink-wrap folks
who say "works great. no warranty once we receive the money." When
was the last time your compiler vendor told you, up front, of the
things which don't work? (On the other hand, report it and it may
turn out that it's a "known bug".) Compare to the latest release
of PC-Word-Mung.
That authors of routines in xxx(3) admit that their routines do
not work in some silly cases (eg: tan(2**31)) also seems commendable.
You are warned to ask sensible questions of the routine. By supplying
this information, the authors enhance software reliability in their
client programs.
--
{gatech!uflorida}!ki4pv!cdis-1!tanner {bpa uunet}!cdin-1!cdis-1!tannerevil@arcturus.UUCP (Wade Guthrie) (03/02/90)
wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > Following are some prime examples of why the C community is thought > of by many as having an unprofessional and irresponsible attitude > toward software reliability: > DAB(!1) [...] FILE(1) [...] JOBS(3J) [...] PARSEDATE(3) [...] > CTAGS(1) [...] EMACS(1) [...] TC(1) [...] UNITS(1) [...] BBEMACS(1) #define FLAME TRUE What do THESE have to do with the C community? I can tell you that I feel myself a member of that community and have NEVER programmed one of these. Moreover, one can put things in "local language" without being irresponsible or cavalier (or are you against Vatican II as well?). Messages such as: > There is a mysterious bug causing occasional core dumps [...] > It often makes mistakes [...] > The grammar is incomplete and always will be [...] > The value of 'tan' for arguments greater than about 2**31 is garbage. > if you have two Pascal procedures in different blocks > with the same name, you lose. and even: > Not bloody likely. > Don't base your financial plans on the currency conversions. are honest indications of where problems may exist, and they do so in language that can be enjoyed by the person reading the manual. Just because the language is not on a par with "Segmentation fault, core dumped", or "Error R2702", or the all-too-famous "Syntax error" doesn't mean that people don't care that the errors are there or that they didn't try to fix them -- it means that the error is recognized and it means that the people writing the manuals are human. It is okay to smile while you are writing your code; enjoyment of ones work allows him to produce more work of a higher quality. > [...] and the fact that C > software seems to erode public confidence in software reliability on a > regular basis (Nationwide Computer Network Infected By Worm; National > Telecommunications System Crashes), The fact that someone can break software does not mean that it is unreliable. Can someone devoting lots of effort break YOUR code? > When is the C community going to clean up its act??? G.M.A.B. (give me a break) > It appears that there is a real need to publicize software engineering > concepts throughout the C community, Throughout ALL software engineering communities. Around here, the Fortran programmers need it a lot more than the C programmers -- not that the C programmers don't. > both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. The whole CONCEPT behind C is to give the programmer a significant amount of power. Power which can be used to do good things or bad. C is a language that does not coddle the programmer; if used with care, C can allow a programmer to do great things. If you believe that power corrupts, however, feel free to use Ada. > [...] If not, > government regulation of the field will probably soon become inevitable. AAAAaaaaahhhhhHHHrrrRRRrrgggggHHHHHH! Government regulation of the private sector? Good God, man; don't you study your history? How about Adam Smith and the invisible hand? If C software is not reliable, let the consumer decide. Letting the government in, well that's just stupid (unless you're talking about Government contracts -- then retract all this stuff). #undef FLAME -- Wade Guthrie (evil@arcturus.UUCP) Rockwell International; Anaheim, CA; My opinions, not my employer's. "All right, so I'm panicking, what else is there to do?"
chrisl@caen.engin.umich.edu (Chris Lang) (03/02/90)
In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Under no circumstances should a DEFECTS section contain flippant > comments such as "I tinker a lot, so things break, but then I fix > them, hooray", "Not bloody likely", or other comments which indicate > a cavalier attitude toward software reliability. > > DEFECTS sections exist for the purpose of listing known areas in > which an implementation does not correspond to the specification, > along with potential workarounds (if any) and the estimated date > of repair. Now compare this with your typical Unix BUGS section. > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu What, may I be so bold, gives you the right to declare what should or should not be put in the documentation for a particular piece of code which you have neither written nor worked on? If such transgressions from the software development community so distress you, why remain a member of it? -Chris ----- Chris Lang University of Michigan, College of Engineering home: 4622 Bursley work: National Center for Manufacturing Sciences Ann Arbor, MI 48109 900 Victors Way, Suite 226 (313) 763-1832 Ann Arbor, MI 48108 chrisl@caen.engin.umich.edu (313) 995-0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/03/90)
From evil@arcturus.UUCP (Wade Guthrie): > [Unix BUGS comments] > are honest indications of where problems may exist, and they do so > in language that can be enjoyed by the person reading the manual. If a currency conversion program is based on the exchange rates as of a given date, then this is a continuation of the specification which does not belong in the DEFECTS section. Under no circumstances should a DEFECTS section contain flippant comments such as "I tinker a lot, so things break, but then I fix them, hooray", "Not bloody likely", or other comments which indicate a cavalier attitude toward software reliability. DEFECTS sections exist for the purpose of listing known areas in which an implementation does not correspond to the specification, along with potential workarounds (if any) and the estimated date of repair. Now compare this with your typical Unix BUGS section. Bill Wolfe, wtwolfe@hubcap.clemson.edu
cathy@gargoyle.uchicago.edu (Cathy Johnston) (03/03/90)
In article <00000NC@cdis-1.UUCP> tanner@cdis-1.UUCP (Dr. T. Andrews) writes: [commenting on Bill Wolfe's complaint that units(1) is documented as only giving an approximate exchange rate...] > >Some of the things cited aren't amenable to change: do you really >expect the currency conversion tables for units(1) to update >themselves every morning from the currency tables in the paper? > Bill's complaint about units(1) is a whole lot sillier than that. In very fast markets, exchange rates change several times a second. And what would you like units(1) to use, Bill? The price in Philadelphia? London? Tokyo? Chicago? Should it give the bid or the ask price? Should it use the spot quote, or maybe the price implied by the option synthetics? How about the price from the futures markets adjusted for stochastic interest rates? I don't need the Wall Street Journal or the exchange rate ticker to tell me that being a millionaire in Lira is no big deal and that "32 Swiss Francs per kilogram" means that lamb chops in Zurich are very expensive. Units(1) is a simple little tool for getting a rough estimate, useful as far as it goes, and *documented*as*just*that. Calling it "evidence" that C programmers are "unprofessional" and "irresponsible" is just, well, "dumb". cathy
jseidman@jarthur.Claremont.EDU (James Seidman) (03/04/90)
In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From evil@arcturus.UUCP (Wade Guthrie): > If a currency conversion program is based on the exchange rates > as of a given date, then this is a continuation of the specification > which does not belong in the DEFECTS section. The manual page for units(1) clearly states that the full list of available units is contained in /usr/lib/units. At least on my machine, this file gives a clear reference for the source of the monetary conversions, including date, newspaper, and exchange. I'll assume you've studied a little software engineering so you'll understand this: The *program* is not based on any exchange rates, it merely accesses a *data file* which contains them. Therefore any vendor can update this data file with newer values. > Under no circumstances should a DEFECTS section contain flippant > comments such as "I tinker a lot, so things break, but then I fix > them, hooray", "Not bloody likely", or other comments which indicate > a cavalier attitude toward software reliability. If I remember your initial post, the "tinker a lot" comment is from BBEMACS and the "Not bloody likely" was from some similarly esoteric program. I don't know who wrote these programs or where you found them, but they may just be some local hack. Would you please check to find out where these programs came from and limit yourself to condemning the appropriate authors? > DEFECTS sections exist for the purpose of listing known areas in > which an implementation does not correspond to the specification, > along with potential workarounds (if any) and the estimated date > of repair. Now compare this with your typical Unix BUGS section. You never define a DEFECTS section. Under what environment do you find these? In any case, my *typical* BUGS section is quite helpful. If you look at the BUGS section for jove(1), cc(1), more(1), msg(1), or any of a host of other programs you will find no flippancy at all. Also, if your complaints are with UNIX, might I suggest that you rant and rave in the UNIX newsgroups? Not all of UNIX is written in C, and by no means is all that is written in C part of UNIX. Having written thousands of lines of C code under MS-DOS and VMS I can testify to this. Lastly, if you are really concerned about this cavalier attitude, why don't you write letters to some of the companies that do C programming? They might not realize how irresponsible their programmers are being. I'm sure that SCO, OSF, Microsoft, Borland, and all those other companies would know exactly what to do with a letter from you explaining how they need to teach their employees about software engineering. -- ------------------------------------------------------------------------------- Jim Seidman, Harvey Mudd College, Claremont, CA 91711. (714) 621-8000 x2026 DISCLAIMER: I don't even know if these are opinions, let alone those of anyone other than me.
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (03/04/90)
In article <8212@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > If a currency conversion program is based on the exchange rates > as of a given date, then this is a continuation of the specification > which does not belong in the DEFECTS section. I see -- your latest strawman is that the manual page for units(1) does not conform to *your* idea of proper documentation format. Well, big f---ing deal. Many of us find it *helpful* to have caveats and bugs called out separately instead of buried in the "specification". ("It ain't a bug -- it's a *Feetchur*!") But I see your strategy -- your new attack draws attention away from your original complaint about units(1), which must have embarassed you horribly when you found out about floating (gasp!) currency exchange rates. > Under no circumstances should a DEFECTS section contain flippant > comments such as "I tinker a lot, so things break, but then I fix > them, hooray", "Not bloody likely", or other comments which indicate > a cavalier attitude toward software reliability. > > DEFECTS sections exist for the purpose of listing known areas in > which an implementation does not correspond to the specification, > along with potential workarounds (if any) and the estimated date > of repair. Now compare this with your typical Unix BUGS section. Well, I have, and except for the "estimated date of repair" part, I find that most UNIX manpage BUGS sections already seem to offer just this information. (BTW, the EDoR of a bug is *not* a documentation issues, a C issue, a UNIX issue, or even a programming issue. It's a product/release management issue. Only after an EDoR has been decided can it be documented.) As for your examples, the ones with "flippant comments" seem to be still more strawmen for your pathetic argument. What the heck is dab(1) anyway? Are you perhaps confusing manpages for a real product with manpages for locally programmed (and documented) extensions to the system? ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/04/90)
From goudreau@larrybud.rtp.dg.com (Bob Goudreau): > your original complaint about > units(1), which must have embarassed you horribly when you found out > about floating (gasp!) currency exchange rates. Right. My self-managed IRA had a total return of 44.43% last year; how embarassing. Maybe I should stop watching the Nightly Business Report so often, huh? > What the heck is > dab(1) anyway? Are you perhaps confusing manpages for a real product > with manpages for locally programmed (and documented) extensions to > the system? Ask Richard D'Ippolito -- he originally posted the list to comp.lang.ada. Unfortunately, the article has already expired at my site. Bill Wolfe, wtwolfe@hubcap.clemson.edu
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (03/04/90)
In article <8223@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > > What the heck is > > dab(1) anyway? Are you perhaps confusing manpages for a real product > > with manpages for locally programmed (and documented) extensions to > > the system? > > Ask Richard D'Ippolito -- he originally posted the list to > comp.lang.ada. Unfortunately, the article has already expired > at my site. So let me get this straight: you're trotting out dab(1) as an example of the "C Community's cavalier attitude on [sic] software reliability", but you don't even have any idea of what dab is. So how on earth do you even know what language it's written in? Not that the language matters anyway. The following are all *orthogonal* concepts (i.e., each may be varied independently of the others): 1) language used to program an application 2) quality of design of the application 3) presence or absence of documentation about bugs 4) presence or absence of "flippant" remarks in the documentation The only parameter that *does* depend (sometimes) on number 1 in the list is: 5) quality of implementation of the application (But note that there are *many* more implementation decisions besides language choice that play a far more important role in determining quality of implementation.) So far, you've shown us numerous strawmen that fall into categories 2, 3 and 4; none of those examples have anything to say about C (or about any other programming language). But you still haven't shown us a relevant example from category 5: an application whose quality of implementation was lowered *solely due to the choice of C as the programming language*. Therefore, I ask you to take the "pep-C challenge": either produce a convincing number of such examples for us, or withdraw your original statements. ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/05/90)
From goudreau@larrybud.rtp.dg.com (Bob Goudreau): > an application whose quality of > implementation was lowered *solely due to the choice of C as the > programming language*. 1) Unix. (Example: the problem in which the double-length password was used by an intruder to bypass security, taking advantage of C's lack of boundary checking) 2) AT&T's phone network (Example: recent crash, which was attributable to C having switch/break instead of a safer case statement) Now practically all programming languages are Turing-complete, so anything which can be written correctly can theoretically be written in any of them. However, some programming languages (e.g., C) are more likely to leave errors undetected than others. Bill Wolfe, wtwolfe@hubcap.clemson.edu
fischer@iesd.auc.dk (Lars P. Fischer) (03/05/90)
In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > FILE(1) It often makes mistakes. Very good. Now give us a solution. Use Ada if you like. Any language. Just write a program that will, given any file, tell me the nature of the data in the file. In fact, I'd be happy to do the programming if you'd just design the algorithm. /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.
fischer@iesd.auc.dk (Lars P. Fischer) (03/05/90)
In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > DEFECTS sections exist for the purpose of listing known areas in > which an implementation does not correspond to the specification, > along with potential workarounds (if any) and the estimated date > of repair. Now compare this with your typical Unix BUGS section. The BUGS section is also intended to point out problems you, as a user, might have with a utility if you are not aware of limitations in the design or the implementation. It is good practice to point out implications of a design decision that the user might not be aware of. /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.
rrr@eleazar.dartmouth.edu (Robin R. Reynolds) (03/05/90)
The Quixotan attacks by Bill Wolfe have not affected my attitudes on C or Ada. They do, however, suggest to me that the net is faced with a religious fanatic of some sort. Dogmatism gets no one anywhere. Prognosis: Not Good. Recommended Treatment: Ignore this guy. He basks in your attention.
trt@rti.UUCP (Thomas Truscott) (03/05/90)
[insert favorite language bashing here] In C I have typed: for (i = 0; i < 100; i++) x[3][i] == 4; In Pascal I have typed: for i := 1 to 100 do; x[3][i] := 4; In Ada I have typed: for i in x'range loop x(3, i) := 4; end loop; These are all "legal", but obviously not what I wanted. A "lint"-like program, ideally the compiler itself, could have warned me about these mistakes, saving me a lot of trouble. The C language (its formal definition) isn't especially dangerous. But "C" (the practical definition) is typically extremely dangerous, thanks to compilers that happily generate code for: *iwonder++; /* why mycode(); /* doesn't */ work = 1<<properly + 3; without a whimper. I remember hearing Steve Johnson (author of lint) complaining that Management would not support additional work on lint. He had pages of notes on improvements he wanted to make. That was 10 years ago. I think lint has actually gotten worse since. By its nature, a "lint"-like capability is hard to formalize. I envision work on it as being fueled by examples of common programming mistakes, and I can imagine fairly sophisticated analysis going on. As an analogy, I will use "spell" to find misspelled words in this news article, but watt I really want is a proofreader. Of course run-time checking is nice too. Remember "Bcc", and "SafeC"? They were commercial flops a few years back. Only now is there a sufficient market for such a package. In summary, I am saying that formal language design can go only so far in preventing programming errors. In fact, I am saying it doesn't go very far at all. Diagnostic compilers &etc are an important part of the CA in CASE. The "C" available on your platform may lack them. So perhaps some other language, with better CA, should be used. Blame it on "C", or the "C compiler". Don't blame it on the "C language". Of course I suppose people will blame it anyway. Let me get the first crack. None of the above errors would have happened in PL/1, because in PL/1 I can simply type: x(4,*) = 3; So there. Tom Truscott
karl@haddock.ima.isc.com (Karl Heuer) (03/05/90)
In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > 1) Unix. (Example: the problem in which the double-length password > was used by an intruder to bypass security, taking > advantage of C's lack of boundary checking) Every instance that I can think of where a password is required, getpass() is used. This routine does its own bounds-checking. I don't suppose you have any more data about this incident? Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
btrue@emdeng.Dayton.NCR.COM (Barry.True) (03/05/90)
In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > 1) Unix. (Example: the problem in which the double-length password > was used by an intruder to bypass security, taking > advantage of C's lack of boundary checking) What has boundary checking got to do with the C Programming Language? It is a problem with the particular implementation or the programmer who coded the program. > > 2) AT&T's phone network (Example: recent crash, which was attributable > to C having switch/break instead of > a safer case statement) > > Now practically all programming languages are Turing-complete, so > anything which can be written correctly can theoretically be written > in any of them. However, some programming languages (e.g., C) are > more likely to leave errors undetected than others. > Again, this is a programmer/implementation problem. Name me one programming language in which a program may be written correctly in which ALL PROGRAMS CAN BE WRITTEN CORRECTLY REGARDLESS OF THE PROGRAMMER DOING THE WRITING OR THE IMPLEMENTATION AND ENVIRONMENT IN WHICH THE PROGRAM IS BEING WRITTEN? Please state facts pertaining to your argument that the C language itself is dangerous/faulty before criticising the C programming community in general. I take great exception to your argument specifically because of this flaw in logic.
joshua@athertn.Atherton.COM (Flame Bait) (03/06/90)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Under no circumstances should a DEFECTS section contain flippant > comments such as "I tinker a lot, so things break, but then I fix > them, hooray", "Not bloody likely", or other comments which indicate > a cavalier attitude toward software reliability. Why not? Personally, I like the lighter tone often found in the BUGS section, and wish more documentation used it. What do you think of programmers (or software engineers) laughing at work? Pretty unprofessional, right? Ban it! Does wearing a T-shirt to work which says "Bugs Rule" show a cavalier attitude toward software reliablity? Maybe you can ban that too. Jeeze. Why don't you put up a sign: "programmers who have fun (or try to) will be branded `unreliable'". > DEFECTS sections exist for the purpose of listing known areas in > which an implementation does not correspond to the specification, Unless you have the specification on line, this is pretty useless. I'm glad the BUGS (or DEFECTS) section lists things that the program doesn't do which a reasonable person might expect it to do, or the reverse. I care more about what the user expects, than what the (usually dusty) specification says. The units program is a great example of this, a reasonable person might be tempted to do his expense report based on the numbers it provides, but the BUGS section warns him of the folly in this. The BUGS section should should also list features which do not work and similar problems, if such exist. But there should be few of these. Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
spicer@apollo.HP.COM (Steve Spicer) (03/06/90)
This 'discussion' sometimes seems more suited for alt.comp.religion than anywhere else. Therefore... Mr. Wolf, I'd love to give up C and learn a new language, so please name one for which the following statement is true: "If it compiles, it must be correct." Don't bother with C, Ada, Modula-2, Pascal,FORTRAN,COBOL,Lisp,Prolog,Basic, or PL/1 -- I've seen programs in each where the compiler did what the programmer said instead of what the programmer meant. I've blamed lousy training, lousy documentation, lousy specs, and occasionally not enough sleep, but I have NEVER blamed the language for my own shortcomings. Steven Spicer
mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) (03/06/90)
In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >> an application whose quality of >> implementation was lowered *solely due to the choice of C as the >> programming language*. > > 1) Unix. (Example: the problem in which the double-length password > was used by an intruder to bypass security, taking > advantage of C's lack of boundary checking) Ah, how quickly they forget. I would like to point out that Unix was heralded as one of the first (if not the first) operating system written in a high level language in order that it could be maintained more easily. This was a radical concept back in the days of handcoded assembly language operating systems. Unfortunately, there are still some companies out there such as Unisys and IBM that still code their major offerings in assembly language, making maintenance and upgrades very difficult indeed. The internet worm took advantage of a poorly designed peice of software which is NOT part of UNIX per se, but rather a library call. The library could have been written in any language. It happened to be written in C, but that is merely coincidental. Sure, you are about to say that if it were written in Pascal, which has stack/array bounds checking, the problem could not have occurred. But there you are wrong as well. Most Pascal compilers nowadays have flags which allow the stack/bounds checking to be turned off, and they usually are in distributed products (at least at the three companies that I worked for that coded in Pascal) because they incur too much overhead, thus slowing down the application. It is unfair to condemn an entire operating system for a single flaw by the way. I will admit that Unix is not flawless, but then, you can't find an operating system that is, so I'm not going to worry about it... > 2) AT&T's phone network (Example: recent crash, which was attributable > to C having switch/break instead of > a safer case statement) You can say that it is a problem with C, but there are other problems which can occur in other languages with the same devastating effects, for example misplaced semi-colons in Pascal, character reversal in Assembly language and just plain typo's. Most programming languages have some level at which they have to trust the programmer. Each language is different, but they all have their faults. C's is the power of the programming language, Ada's is the sheer bulk of the final code. ("What do you mean that it is going to take over 150 Megabytes of Virtual memory just to compile your code?", a question that I asked an individual who was requiring a machine reconfiguration on a network that I was administring.) > Now practically all programming languages are Turing-complete, so > anything which can be written correctly can theoretically be written > in any of them. However, some programming languages (e.g., C) are > more likely to leave errors undetected than others. Like I said, at some point you have to trust the programmer. If the programmer knows what they are doing, knows the language and is alert, 90% of the bugs would be caught during coding. However, programmers are human, and errors are made. That is life. It will be interesting to see the first time that a well publicized programming bug is discovered in an Ada application: here is a multi-million dollar language that was designed by commitee to assure "quality" software. Are you going to say that Ada programmers produce perfect code? If you are, I can produce some that will tell you exactly how wrong you are... -- Mark H. Colburn If you don't make money off of it, Open Systems Architects, Inc. it had better be either a religious mark@Minnetech.MN.ORG experience or a hobby. - Lance Cooper
freek@fwi.uva.nl (Freek Wiedijk) (03/06/90)
>Sure, you are about to say that if it were written in Pascal, ...
Wrong. Completely wrong. He was about to say that "if it were written
in Ada, ..."
--
Freek "the Pistol Major" Wiedijk Path: uunet!fwi.uva.nl!freek
#P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**eric@snark.uu.net (Eric S. Raymond) (03/06/90)
In <16085@haddock.ima.isc.com> Karl Heuer wrote: > In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > 1) Unix. (Example: the problem in which the double-length password > > was used by an intruder to bypass security, taking > > advantage of C's lack of boundary checking) > > Every instance that I can think of where a password is required, getpass() is > used. This routine does its own bounds-checking. I don't suppose you have > any more data about this incident? This sounds like a somewhat garbled description of a known hole in SunOS. As Sun still hasn't fixed it, I shall say no more about it here. E-mail inquiries from root or anyone whose name I can instantly recognize as a Good Guy will be answered in more detail. -- Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)
hamish@mate.sybase.com (Just Another Deckchair on the Titanic) (03/08/90)
In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > [...] > Now practically all programming languages are Turing-complete, so > anything which can be written correctly can theoretically be written > in any of them. However, some programming languages (e.g., C) are > more likely to leave errors undetected than others. IMO this is the first time on this forum that Bill has articulated the real issue behind the recent postings without needlessly inflamotory adjectives and irrelevant "evidence". What he says above is (again, IMO) correct (but vague enough to be unasailable) - and rather different to saying that the "C community" (whatever *that* may be...) has a cavalier attitude towards software engineering. But what troubled me during the recent flame fest has been that the discussion has (deliberately?) revolved around the *easy problem* in software engineering - particular language insecurities. This is something that with careful supervision and standard engineering techniques is solvable in a way that the Big Problems - understanding and specifying the problem and solution in manageable, understandable, coherent and provably correct ways- are not. Not an easy task. In that context, particular (and debatable) insecurities in C are barely worth mentioning except in passing. Perhaps the focus was on language insecurites *because* we can't solve the bigger problems - and because it's the easier target? Hamish ---------------------------------------------------------------------------- Hamish Reid Sybase Inc, 6475 Christie Ave, Emeryville CA 94608 USA +1 415 596-3917 hamish@sybase.com ...!{mtxinu,sun}!sybase!hamish
reggie@dinsdale.nm.paradyne.com (George W. Leach) (03/16/90)
In article <8616@sybase.sybase.com> hamish@sybase.com.(Just Another Deckchair on the Titanic) writes: >Perhaps the focus was on language insecurites *because* we can't solve >the bigger problems - and because it's the easier target? It is easier also to find a "silver bullet" that one can champion. How often have we seen this in the past? George George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA