C Community's Cavalier Attitude On Software Reliability

[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:
  
   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 at hubcap.clemson.edu