On Fri, 22 February 2008 23:28:58 +0100, Krzysztof Halasa wrote:I strongly disagree. Machine-generated warnings are a great way of quickly locating a large amount of questionable code in an otherwise overwhelming haystack. It doesn't even matter much, which warnings you look for. Almost all code checkers find the same hotspots. But there is a catch. If you have an over-eager warning police that "fixes all the warnings", the warnings may be gone, but the very real problems in near vicinity are not. Not to mention new problems introduced by those claimed "fixes". One fun hobby in my last job was to write a new code checker and locate those problem areas hidden behind warning-free code. I had to write a new checker so I would see below the polish of "fixes". The actual problems found by the checker were often trivial and near-meaningless. But those warnings are not the point at all, quite the contrary. The only important thing was "that code might have other problems nearby". Note one scary consequence: code checkers in the wrong hands are actively harmful. Jörn -- One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson. --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Mike Travis | [RFC 00/15] x86_64: Optimize percpu accesses |
| Dave Jones | agp / cpufreq. |
| Willy Tarreau | Re: [PATCH] tcp: splice as many packets as possible at once |
| Gerrit Renker | [PATCH 14/37] dccp: Tidy up setsockopt calls |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
