"Strong typing vs. strong testing"

[RG]

In article <lniq1n45ht.fsf at nuthaus.mib.org>,
 Keith Thompson <kst-u at mib.org> wrote:

> RG <rNOSPAMon at flownet.com> writes:
> [...]
> > You can't have it both ways.  Either I am calling it incorrectly, in 
> > which case I should get a compiler error, or I am calling it correctly, 
> > and I should get the right answer.  That I got neither does in fact 
> > falsify the claim.  The only way out of this is to say that 
> > maximum(8589934592, 1) returning 1 is in fact "correct", in which case 
> > we'll just have to agree to disagree.
> 
> You are calling maximum() incorrectly, but you are doing so in a way
> that the compiler is not required to diagnose.

Yes.  I know.  That was my whole point.  There are ways to call a 
function incorrectly (more broadly, there are errors in code) that a C 
compiler is not required to diagnose.

> If you want to say that the fact that the compiler is not required
> to diagnose the error is a flaw in the C language, I won't
> argue with you.

I'm not even saying it's a flaw in the language.  All I'm saying is that 
the original claim -- that any error in a C program will be caught by 
the compiler -- is false, and more specifically, that it can be 
demonstrated to be false without appeal to unknown run-time input.

As an aside, this particular error *could* be caught (and in fact would 
be caught by other tools like lint), but there are errors that can not 
be caught by any static analysis, and that therefore one should not be 
lulled into a false sense of security by the fact that your code is 
written in a statically typed language and compiled without errors or 
warnings.  That's all.

> If I write:
> 
>     const double pi = 22.0/7.0;
>     printf("pi = %f\n", pi);
> 
> then I suppose I'm calling printf() incorrectly, but I wouldn't
> expect my compiler to warn me about it.
> 
> If you're arguing that
> 
>     int maximum(int a, int b) { return a > b ? a : b; }
> 
> is flawed because it's too easy to call it incorrectly, you're
> effectively arguing that it's not possible to write correct
> code in C at all.

I would say that it is very, very hard to write correct code in C for 
any non-vacuous definition of "correct".  That is the reason that core 
dumps and buffer overflows are so ubiquitous.  I prefer Lisp or Python, 
where core dumps and buffer overflows are virtually nonexistent.  One 
does get the occasional run-time error that might have been caught at 
compile time, but I much prefer that to a core dump or a security hole.

One might hypothesize that the best of both worlds would be a dynamic 
language with a static analyzer layered on top.  Such a thing does not 
exist.  It makes an instructive exercise to try to figure out why.  (For 
the record, I don't know the answer, but I've learned a lot through the 
process of pondering this conundrum.)

rg