"Strong typing vs. strong testing"
usenet-nospam at seebs.net
Thu Sep 30 18:49:16 CEST 2010
On 2010-09-30, RG <rNOSPAMon at flownet.com> wrote:
> My code compiles with no warnings under gcc -Wall.
That's nice. gcc -Wall uses only a small subset of warnings that fit
the usual expectations of C code that's trying to work on common
>> 2. The constant is not of type int, and the compiler will warn you about
>> this if you ask.
> It would be nice if this were true, but my example clearly demonstrates
> that it is not.
No, it doesn't, because you didn't ask for the relevant kind of warnings.
> And if your response is to say that I should have used
> lint, then my response to that will be that because of the halting
> problem, for any static analyzer that you present, I can construct a
> program that either contains an error that either your analyzer will not
> catch, or for which it will generate a false positive. It just so
> happens that constructing such examples for standard C is very easy.
I'm not sure that that's actually a halting problem case. The thing about
static typing is that we don't actually HAVE to solve the halting problem;
we only have look at the types of the components, all of which are knowable
at compile time, and we can tell you whether there's any unsafe conversions.
And that's the magic of static typing: It is not a false positive to
warn you that "2L" is not of type int. There are things which would be a
false positive in trying to determine whether something will be out of range
in a runtime expression, but which are not false positives in a statically
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam at seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
More information about the Python-list