"Strong typing vs. strong testing"

RG rNOSPAMon at flownet.com
Thu Sep 30 06:57:46 CEST 2010


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

> RG <rNOSPAMon at flownet.com> writes:
> [...]
> > That the problem is "elsewhere in the program" ought to be small 
> > comfort.
> 
> I don't claim that it's comforting, merely that it's true.
> 
> >           But very well, try this instead:
> >
> > [ron at mighty:~]$ cat foo.c
> > #include <stdio.h>
> >
> > int maximum(int a, int b) { return a > b ? a : b; }
> >
> > int main() {
> >   long x = 8589934592;
> >   printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> >   return 0;
> > }
> > [ron at mighty:~]$ gcc -Wall foo.c 
> > [ron at mighty:~]$ ./a.out 
> > Max of 8589934592 and 1 is 1
> 
> That exhibits a very similar problem.
> 
> 8589934592 is 2**33.
> 
> Given the output you got, I presume your system has 32-bit int and
> 64-bit long.  The call maximum(x, 1) implicitly converts the long
> value 8589934592 to int.  The result is implementation-defined,
> but typically 0.  So maximum() is called with arguments of 0 and 1,
> as you could see by adding a printf call to maximum().
> 
> Even here, maximum() did exactly what was asked of it.

Of course.  Computers always do only exactly what you ask of them.  On 
this view there is, by definition, no such thing as a bug, only 
specifications that don't correspond to one's intentions.  
Unfortunately, correspondence to intentions is the thing that actually 
matters when writing code.

> I'll grant you that having a conversion from a larger type to a smaller
> type quietly discard high-order bits is unfriendly.

"Unfriendly" is not the adjective that I would choose to describe this 
behavior.

There is a whole hierarchy of this sort of "unfriendly" behavior, some 
of which can be caught at compile time using a corresponding hierarchy 
of ever more sophisticated tools.  But sooner or later if you are using 
Turing-complete operations you will encounter the halting problem, at 
which point your compile-time tools will fail.  (c.f. the Collatz 
problem)

I'm not saying one should not use compile-time tools, only that one 
should not rely on them.  "Compiling without errors" is not -- and 
cannot ever be -- be a synonym for "bug-free."

rg



More information about the Python-list mailing list