I got emailed summaries from a Coverity scan of the repo head version of GPSD today.
Analysis summary report:
------------------------
Files analyzed : 86
Total LoC input to cov-analyze : 72824
Functions analyzed : 585
Classes/structs analyzed : 128
Paths analyzed : 125590
Time taken by Coverity analysis : 00:01:22
Defect occurrences found : 45 Total
2 BAD_SIZEOF
2 CHECKED_RETURN
4 CONSTANT_EXPRESSION_RESULT
3 DEADCODE
12 FORWARD_NULL
1 INFINITE_LOOP
1 NEGATIVE_RETURNS
1 NULL_RETURNS
1 OVERRUN_DYNAMIC
3 OVERRUN_STATIC
6 RESOURCE_LEAK
1 REVERSE_INULL
7 UNINIT
1 UNREACHABLE
Those of you who’ve seen Coverity scans before will know that (1) a defect rate of 1 per 1.68KLOC is pretty damned good to begin with, and (2) some of those reports are probably false positives.
I am extremely pleased, and looking forward to analyzing the detail logs.
UPDATE: Oops. Misplaced a decimal point on first post.
Er…math…
Try 1.68KLOC (unless I’m missing something). Still very nice though.
>Try 1.68KLOC (unless I’m missing something). Still very nice though.
Urgh. Did I drop a decimal point? Stupid bc…I’ll check.
Now you have the decimal point in the right spot, but have replaced it with a comma. (Which won’t bother your European readers, but might confuse the Americans).
>Now you have the decimal point in the right spot, but have replaced it with a comma. (Which won’t bother your European readers, but might confuse the Americans).
Frickin’ small fonts on a browser. I couldn’t see the comma tail – maybe I need a new monitor. Corrected x2.
“maybe I need a new monitor”
Yes. Yes you do. Any lower refresh rate on that puppy and it would qualify as a slide show.
45 defects / (72824 LoC / 1000) ? 0.618 defects / KLoC, not 1.618 defects / KLoC.
@jsn: He said 1 defect / 1.618 KLoC, not 1.618 defects / KLoC.
@Jon Brase: Duh, of course. Thanks for pointing that out.
On a more serious note, the company I work for has been using Coverity for some years now. In my experience, about half of the issues found end up being something which is (or could be, maybe) a problem. Part of the problem is that Coverity can’t really understand the semantics of the code.
For example, consider a data structure with two members. The first is a type parameter and the second is some sort of value. When created, the type might be explicitly set to 0, meaning nothing. In this case, the value parameter has no meaning whatsoever. However, Coverity will complain that the value parameter hasn’t been initialized before use. Of course, any time the type is set to something other than 0, the value parameter is then initialized, so it isn’t a big problem. (Yes, this tends to crop up more in C++ which doesn’t apply in this case, but still).
That having been said, Coverity does help you re-think your code a fair bit. If you pass in a pointer to a function, dereference it at some point and then later check to see if the pointer is NULL, Coverity will point out that your own code assumes that the pointer coming in could be null and is being dereferenced in that state. Maybe the pointer can never be NULL and it’s just a superfluous check, which you can get rid of and make the code cleaner. Maybe it could be NULL and you could crash – at least now you know what to look at. In either case, it at least gives you things to look at and perhaps clean up.
I’m not familiar with Coverity, though I am familiar with similar tools that perform static analysis on code. One of the reasons I like languages like C# is because they are far easier for tools to analyze for this kind of thing. Why? For two reasons, they don’t have the ungodly complexity of a language like C++, and they share an abundance of semantic data through the static type system that Python, Javascript and all those other new kids on the block seem to think best to not talk about. C stands in the middle being a much simpler language, but the type system is considerably less rich.
Microsoft tools are spectacular for this kind of thing, especially when augmented by extended static analysis tools like fxCop, or add ons like Resharper. It is why I produce the lowest zero day bugs in C# than I have in any other programming language. For the most part, when I type a program in C#, it is right almost in every particular first time. (This is partly due to Intelisense editor tools too, but you get the picture.)
C# goes further too in actually having a knowledge base of data about some specific types which it can validate against typical usage patterns, and it can also validate higher level ideas like I18n, validation of web service contracts, etc. etc.
Microsoft do lots of things badly, but they do developer tools really, really well. I once tried XCode, it was horrible. (Yes, Eclipse is pretty nice.) I also write a lot of javascript. It is so much more prone to bugs that C#, it just isn’t funny even if you wrap it in jquery.
Higher error rate in the post about errors in the code, than in the code itself :)
@jsn
Ooh. It’s the golden ratio. Which means you have to be especially careful doing sums as it and its reciprocal look suspiciously similar (being identical after the decimal point)
…if you’re writing vertical-market apps. If you’re writing OS components (like web browsers) or other programs that compete with Microsoft’s offerings, Microsoft will still obstruct you any way they can. The EULA for Visual Studio did, and might still, contain clauses that expressly banned you from writing a word processor or spreadsheet with the tool.
That said, Jessica, substitute Ada for C# in the above and I agree with you 100%. Ada — particularly the SPARK dialect, a formally verifiable subset that forbids certain constructs and adds contracts which are checked in a verification step — is literally a major part of the reason why fly-by-wire jets are so safe.
You strike me as the type whose personal road to hackerdom would probably be by way of Haskell, which has arguably the world’s richest static type system for a practical language. The feeling of “if it compiles, it probably works” pervades Haskell programming, but figuring out the details will challenge your mind. In Haskell you don’t feed the dog, you pass the dog food as a parameter and it returns a world-state in which lies an empty food bowl.
@Jeff I don’t know a great deal about Ada, though I have looked a little, and the ecosystem seems very pro-tool, pro-static analysis, which is definitely playing in my ballpark. So you may very well be right, I could probably learn a lot from learning more about it (I did take a short course in college about it, so I remember it is very Pascal-y, Modula-y., and if I remember rightly, very verbose, which I am not a huge fan of.)
I also have done a little Haskell, and I think all programmers should, because it kind of requires you to turn your imperative programming brain inside out. I think it really helps you think about programming in a much better way.
FWIW, C# has many declarative features which are really appealing to me such as LINQ and PLINQ, along with things like lazy evaluation with yield. By no means a pure functional language, but certainly it has features in the declarative style, much like some parts of SQL.
I personally really like these features, but unfortunately they are too hard for the average programmer to get their brain around, so I tend to not use them too much. :-(
Ada verbosity can be managed with things like
renamesconstructs and judicious use of subtypes. So it’s not verbose in quite the same sense as, say, COBOL, which has considerable irreducible verbosity.Well-written Ada code is not much more verbose than the equivalent C++ — in some cases less depending on how templaty the C++ is — and is usually better structured and more readable. Those are good things.
Ah, yes, the Average Programmer — cousin to the mythical creature Average User.
In all seriousness, notwithstanding the notoriety of “enterprise application development” as a moron incubator, the median programmer is a good deal smarter — and his mind more malleable and open to new concepts — than Aunt Tilly. So I really see no reason to withhold useful advanced language features from him.