In article <lnk4m45eu0....@nuthaus.mib.org>,
 Keith Thompson <ks...@mib.org> wrote:

> RG <rnospa...@flownet.com> writes:
> > In article 
> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> >  Squeamizh <sque...@hotmail.com> wrote:
> >> On Sep 29, 3:02 pm, RG <rnospa...@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:
> >> >
> >> > [...@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;}
> >> >
> >> > [...@mighty:~]$ gcc -Wall foo.c
> >> > [...@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.

If you try to refine this claim so that it is both correct and 
non-vacuous you will find that static typing does not do nearly as much 
for you as most of its adherents think it does.

> >> We are all aware that there is no perfect software development process
> >> or tool set.  I'm interested in minimizing the number of problems I
> >> run into during development, and the number of bugs that are in the
> >> finished product.  My opinion is that static typed languages are
> >> better at this for large projects, for the reasons I stated in my
> >> previous post.
> >
> > More power to you.  What are you doing here on cll then?
> 
> This thread is cross-posted to several newsgroups, including
> comp.lang.c.

Ah, so it is.  My bad.

rg
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to