C Community's Cavalier Attitude On Software Reliability

Thomas Truscott trt at rti.UUCP
Mon Mar 5 11:48:34 AEST 1990


[insert favorite language bashing here]

In C I have typed:

	for (i = 0; i < 100; i++)
	    x[3][i] == 4;

In Pascal I have typed:

	for i := 1 to 100 do;
	    x[3][i] := 4;
		
In Ada I have typed:

	for i in x'range loop
	    x(3, i) := 4;
	end loop;


These are all "legal", but obviously not what I wanted.
A "lint"-like program, ideally the compiler itself,
could have warned me about these mistakes,
saving me a lot of trouble.

The C language (its formal definition) isn't especially dangerous.
But "C" (the practical definition) is typically extremely dangerous,
thanks to compilers that happily generate code for:

	*iwonder++;	/* why
	mycode();	/* doesn't */
	work = 1<<properly + 3;

without a whimper.  I remember hearing Steve Johnson (author of lint)
complaining that Management would not support additional work
on lint.  He had pages of notes on improvements he wanted to make.
That was 10 years ago.  I think lint has actually gotten worse since.

By its nature, a "lint"-like capability is hard to formalize.
I envision work on it as being fueled by examples of common programming
mistakes, and I can imagine fairly sophisticated analysis
going on.  As an analogy, I will use "spell" to find misspelled words
in this news article, but watt I really want is a proofreader.

Of course run-time checking is nice too.  Remember "Bcc", and "SafeC"?
They were commercial flops a few years back.
Only now is there a sufficient market for such a package.

In summary, I am saying that formal language design can go only so far
in preventing programming errors.  In fact, I am saying
it doesn't go very far at all.  Diagnostic compilers &etc
are an important part of the CA in CASE.
The "C" available on your platform may lack them.
So perhaps some other language, with better CA, should be used.
Blame it on "C", or the "C compiler".  Don't blame it on the "C language".

Of course I suppose people will blame it anyway.
Let me get the first crack.
None of the above errors would have happened in PL/1,
because in PL/1 I can simply type:

	x(4,*) = 3;

So there.
	Tom Truscott



More information about the Comp.lang.c mailing list