In article <lnbp7g58b4....@nuthaus.mib.org>,
Keith Thompson <ks...@mib.org> wrote:
> RG <rnospa...@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:
> >
> > [...@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;
> > }
> > [...@mighty:~]$ gcc -Wall foo.c
> > [...@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
--
http://mail.python.org/mailman/listinfo/python-list
