C Community's Cavalier Attitude On Software Reliability

[Mark H. Colburn]

In article <8147 at hubcap.clemson.edu> wtwolfe at 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 at Minnetech.MN.ORG		    experience or a hobby. 
							- Lance Cooper