"Strong typing vs. strong testing"

[RG]

In article <lnzkuz2emv.fsf at nuthaus.mib.org>,
 Keith Thompson <kst-u at mib.org> wrote:

> 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
> 
> [...]

That gives (what I would consider to be) false positives, e.g.:

[ron at mighty:~]$ cat foo.c

void foo(long x) {}

int main() { foo(1); }
[ron at mighty:~]$ gcc -Wconversion foo.c
foo.c: In function ‘main’:
foo.c:4: warning: passing argument 1 of ‘foo’ 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.

Actually I have.  Twice now.  Remember, the claim is not that the 
compiler will fail to warn.  It's trivial to never fail to warn simply 
by always warning.  The claim is that the compiler with *either* fail to 
warn *or* generate false positives.  So you have to choose your compiler 
(and flags) first, and then I get to construct my example.  If my 
example has *either* an error that the compiler doesn't catch *or* a 
non-error that it does catch then I win.

Want to try another round?

rg