Xref: utzoo comp.software-eng:2982 comp.lang.c:26431
Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!samsung!emory!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.software-eng,comp.lang.c
Subject: Re: Errors aren't that simple
Message-ID: <8192@hubcap.clemson.edu>
Date: 28 Feb 90 20:04:56 GMT
References: <39400075@m.cs.uiuc.edu>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 55

From marick@m.cs.uiuc.edu:
> There are two assertions in Bill Wolfe's message:
> 1.  The C community releases an unacceptable number of errors.
> 2.  The C language is at least partly the *cause* of those errors.

  3.  Many members of the C community exhibit an unprofessional and
        irresponsible attitude regarding defect control and especially
        defect prevention.   

  4.  Those members of the C community who ARE responsible professionals
        are apparently not taking significant actions to raise the level
        of software engineering professionalism within the C community.  

   The unsafe constructs within C are themselves sufficient evidence to
   conclude that the C community, by choosing to use a language which has
   many highly unsafe constructs and an almost total disregard for error 
   prevention, does not hold error prevention in sufficiently high regard;
   the failure of a password security system because no boundary checks 
   were done on the length of the password (whereupon the intruder purposely
   supplied a double-length password and thereby ensured that the left and
   right sections of the password-validating data structure were compatible),
   and similar cases demonstrate that the C language poses a serious obstacle
   to the development of defect-minimal software.  For the cost of simply
   the recent national AT&T crash, I'd be willing to conjecture that all of 
   AT&T's software developers could have been trained in software engineering
   concepts and the Ada language, and supplied with Ada compilers as well.   

   The comments found in the Unix man pages I cited have been there for 
   at least a decade, apparently going unchallenged by the rest of the 
   C community.  This is despite the fact that the growth of C has been 
   widely attributed to the Unix operating system being given away to 
   so many universities -- if this attribution is correct, then Unix is
   also responsible for helping to create the widespread attitude within 
   the C community that defects are to be treated casually.  

   It is entirely true that other language communities (BASIC, COBOL, etc.)
   have problems along these lines which are arguably worse than those which
   are clearly associated with the C community.  On the other hand, there are
   other language communities which are doing a considerably better job of
   spreading software engineering concepts and providing linguistic support
   for their application (Ada, Eiffel, etc.).  The challenge for the C
   community is to join the language communities which are doing a good
   job in these respects, as opposed to holding its existing reputation
   as a community which contains an extremely high percentage of those who
   regard themselves as hackers, and whose products repeatedly make national 
   headlines with their spectacular failures.  Since C is a language which
   provides little or no support for defect prevention, one would expect
   that the C community would naturally compensate by being extremely 
   careful about always applying the very best software engineering 
   practices.  Unfortunately, I don't think even the most dedicated 
   C-backers would attempt to claim that this is presently the case.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu