"Strong typing vs. strong testing"

[Keith Thompson]

RG <rNOSPAMon at flownet.com> writes:
> 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.

Of course.

>> 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.

Did someone *really* claim that "any error in a C program will
be caught by the compiler"?  If so, I must have missed that.
It's certainly not true; code that compiles cleanly can be riddled
with errors.  That's true in any language, but more so in C than
in some others.

> 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.

I don't believe anyone has said otherwise.

>> 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.

I would say that it can certainly be difficult to write correct
code in C, but I don't believe it's nearly as hard as you think
it is.  It requires more discipline than some other languages,
and it can require some detailed  knowledge of the language itself,
particularly what it defines and what it doesn't.  And it's not
always worth the effort if another language can do the job as well
or better.

> 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.)

-- 
Keith Thompson (The_Other_Keith) kst-u at mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"