Weekly Edition
Return to the Kernel page
| |||||||||||||
Stanse
Static analysis tools can bring great value to the development process;
they often find bugs which escape review and which, potentially, can live
in the code base for years. Linux has benefited from bug reports from
Coverity's tools, but those tools are proprietary. Unfortunately, free
static analysis tools have always lagged the proprietary alternatives.
That won't change overnight, but there is a new contender on the block in the form of Stanse; the 1.0 version was recently announced on the kernel mailing list. Specific problems that Stanse can test for include locking errors, memory leaks, failure to check for memory allocation failures, non-atomic operations in atomic context, and some reference counting errors. A list of kernel bugs found by Stanse has been posted. Clearly, it would be nice to extend Stanse with more tests. Many kernel developers may balk at doing that, though; Stanse is a Java application, and checker rules must be written in XML. That limits rule additions to those who are both familiar with kernel code and able to work in a Java/XML environment. (Log in to post comments)
Stanse Posted Oct 16, 2009 1:46 UTC (Fri) by vomlehn (subscriber, #45588) [Link]
XML is pretty darn simple, so even we low-brow kernel developers should be able to pick *that* up. Java is a bit harder, but after you've been in the programming game a while, it's just one more programming language. Bottom line: if this thing really works, we should use it.
Stanse Posted Oct 16, 2009 21:29 UTC (Fri) by oak (subscriber, #2786) [Link]
> XML is pretty darn simple
Simple? Yes[1].
[1] to some definition of simple, see the XML spec (namespaces etc).
Stanse Posted Oct 16, 2009 21:47 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
I think the readability depends heavily on the schema that's selected for the XML.
what most people end up using is insane, but I believe that properly used it can be good.
many people do something like
which I agree is horrible to deal with
however if you did something like this instead
I think it's reasonable.
my view is that if the item of data can only appear once it should be an attribute, only if it can appear multiple times or can have something else inside it should it be an element (and even there I sometimes 'cheat' by making the data be a comma separated list)
Stanse Posted Oct 18, 2009 4:51 UTC (Sun) by dang (guest, #310) [Link]
So use any of the many off the shelf tools and access the underlying data structure through a friendly UI? You'd kinda want to do that anyway so that you could validate your edits against the schema, no?
Stanse Posted Oct 16, 2009 4:12 UTC (Fri) by jordanb (guest, #45668) [Link]
I love it how if you're a Java programmer, XML is the hammer and just about anything requiring any sort of meta-data is the screw.
There's a static analysis tool for Ada that was released as free software some time ago, called SPARK. It uses annotations embedded in comments. That seems the most sane way to go. Trying to maintain parallel XML files for annotations seems like pure horror. And since you have to parse the C file anyway it's no more work to provide a mechanism to keep the annotations inline.
Stanse Posted Oct 16, 2009 5:08 UTC (Fri) by cpeterso (guest, #305) [Link] re ADA SPARK: Splint (LCLint) and Linus' own Sparse are a similar annotation checkers for C. They are promising but require a lot of patience.
Stanse Posted Oct 21, 2009 3:37 UTC (Wed) by pflugstad (subscriber, #224) [Link] I love it how if you're a Java programmer, XML is the hammer and just about anything requiring any sort of meta-data is the screw.Or even, if there is no meta-data, XML is still the answer for many Java programmers. 1000+ lines of XML to configure a simple GUI window that is just displaying a fixed data structure.
Stanse Posted Oct 22, 2009 0:02 UTC (Thu) by nix (subscriber, #2304) [Link]
Hah. Look up XQueryX if you want unreadable. If the job is scripting, an
XML parse tree is *really really* not the answer.
Stanse Posted Oct 26, 2009 0:01 UTC (Mon) by mgwmgw@comcast.net (guest, #61583) [Link]
I am an experienced Java and XML developer, who is currently between jobs.
If the primary issue in this stanse discussion is that we want to add more rules, then the fact that the rules are interpreted by Java does not matter.
If people find that XML is not how they want to express the rules, then if we can identify another way that people want to express the rules, then if the other way is functionally equivalent to XML, it would be relatively easy to write something to translate from that other language into functionally equivalent XML. Another alternative is to create a GUI front-end to edit the XML without a human actually having to look at it.
So, if not in XML, how would we want to express the static rules?
|
|||||||||||||