C Community's Cavalier Attitude On Software Reliability

[Henry Spencer]

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:

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 at zoo.toronto.edu