"Strong typing vs. strong testing"

Vend vend82 at virgilio.it
Thu Sep 30 18:02:30 EDT 2010


On 30 Set, 01:47, RG <rNOSPA... at flownet.com> wrote:
> In article <lnk4m45eu0.... at nuthaus.mib.org>,
>  Keith Thompson <ks... at mib.org> wrote:
>
>
>
> > RG <rNOSPA... at flownet.com> writes:
> > > In article
> > > <07f75df3-778d-4e3d-8aa0-fbd4bd108... at k22g2000prb.googlegroups.com>,
> > >  Squeamizh <sque... at hotmail.com> wrote:
> > >> On Sep 29, 3:02 pm, RG <rNOSPA... at flownet.com> wrote:
> > [...]
> > >> > This is a red herring.  You don't have to invoke run-time input to
> > >> > demonstrate bugs in a statically typed language that are not caught by
> > >> > the compiler.  For example:
>
> > >> > [ron at mighty:~]$ cat foo.c
> > >> > #include <stdio.h>
>
> > >> > int maximum(int a, int b) {
> > >> >   return (a > b ? a : b);
>
> > >> > }
>
> > >> > int foo(int x) { return 9223372036854775807+x; }
>
> > >> > int main () {
> > >> >   printf("%d\n", maximum(foo(1), 1));
> > >> >   return 0;}
>
> > >> > [ron at mighty:~]$ gcc -Wall foo.c
> > >> > [ron at mighty:~]$ ./a.out
> > >> > 1
>
> > >> > Even simple arithmetic is Turing-complete, so catching all type-related
> > >> > errors at compile time would entail solving the halting problem.
>
> > >> > rg
>
> > >> In short, static typing doesn't solve all conceivable problems.
>
> > > More specifically, the claim made above:
>
> > >> in C I can have a function maximum(int a, int b) that will always
> > >> work. Never blow up, and never give an invalid answer.
>
> > > is false.  And it is not necessary to invoke the vagaries of run-time
> > > input to demonstrate that it is false.
>
> > But the above maximum() function does exactly that.  The program's
> > behavior happens to be undefined or implementation-defined for reasons
> > unrelated to the maximum() function.
>
> > Depending on the range of type int on the given system, either the
> > behavior of the addition in foo() is undefined (because it overflows),
> > or the implicit conversion of the result to int either yields an
> > implementation-defined result or (in C99) raises an
> > implementation-defined signal; the latter can lead to undefined
> > behavior.
>
> > Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> > the addition yields the value 0, but the C language doesn't require that
> > particular result.  You then call maximum with arguments 0 and 1, and
> > it quite correctly returns 1.
>
> This all hinges on what you consider to be "a function maximum(int a,
> int b) that ... always work[s] ... [and] never give[s] an invalid
> answer."  But if you don't consider an incorrect answer (according to
> the rules of arithmetic) to be an invalid answer then the claim becomes
> vacuous.  You could simply ignore the arguments and return 0, and that
> would meet the criteria.

But in your own example the function maximum() does give the correct
answer, therefore your point doesn't stand.




More information about the Python-list mailing list