RG <rnospa...@flownet.com> writes: > In article <slrnia9cpd.2uqe.usenet-nos...@guild.seebs.net>, > Seebs <usenet-nos...@seebs.net> wrote: > >> On 2010-09-30, Lie Ryan <lie.1...@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) ks...@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" -- http://mail.python.org/mailman/listinfo/python-list