Xref: utzoo comp.lang.c:26380 comp.software-eng:2956 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!srcsip!jhereg!mark From: mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) Newsgroups: comp.lang.c,comp.software-eng Subject: Re: C Community's Cavalier Attitude On Software Reliability Keywords: Unprofessional Irresponsible Message-ID: <1990Feb28.063643.13294@Jhereg.Minnetech.MN.ORG> Date: 28 Feb 90 06:36:43 GMT References: <8147@hubcap.clemson.edu> Organization: Open Systems Architects, Inc., Mpls, MN Lines: 146 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