"Strong typing vs. strong testing"

Keith Thompson kst-u at mib.org
Thu Sep 30 15:52:08 EDT 2010


RG <rNOSPAMon at flownet.com> writes:
> In article <slrnia9cpd.2uqe.usenet-nospam at guild.seebs.net>,
>  Seebs <usenet-nospam at seebs.net> wrote:
>
>> On 2010-09-30, Lie Ryan <lie.1296 at gmail.com> wrote:
>> > On 09/30/10 16:09, TheFlyingDutchman wrote:
>> >> Dynamic typed languages like Python fail in this case on "Never blows
>> >> up".
>> 
>> > How do you define "Never blows up"?
>> 
>> I would say "blow up" would be "raise an exception".
>> 
>> > Personally, I'd consider maximum(8589934592, 1) returning 1 as a blow
>> > up, and of the worst kind since it passes silently.
>> 
>> So run your compiler with a decent set of warning levels, and watch as
>> you are magically warned that you're passing an object of the wrong type.
>
> My code compiles with no warnings under gcc -Wall.

Conclusion: "-Wall" is not "a decent set of warning levels" in this
context, in spite of the name.  (If you want to complain that the
name "-Wall" is misleading, I won't disagree, but it's a gcc issue,
not a C issue.)

With "-Wconversion", I get:

c.c: In function 'main':
c.c:7: warning: passing argument 1 of 'maximum' with different width due to prototype

[...]

>> On any given system, one or the other is true:
>> 
>> 1.  The constant 8589934592 is of type int, and the function will
>> "work" -- will give that result.
>> 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.  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.

And yet you have not managed to do it.

It seems to me that the line between errors that a sufficiently
clever compiler could or should warn you about, and errors that
compilers cannot reasonably be expected to detect, is a very
fuzzy one.  A fairly clear example of the latter is:

    const double pi = 2.71828182845904523526;

To a human reader, it's obviously either a mistake or deliberate
obfuscation, but I'm not sure I'd *want* my compiler to warn me
about it just because I named the object "pi" rather than "e".
(And if I called it "x", even an intelligent human wouldn't know
that it's wrong.)

-- 
Keith Thompson (The_Other_Keith) kst-u at mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"



More information about the Python-list mailing list