I'm glad this is a popular thread. > Alan Coopersmith wrote: > When I asked the Coverity guys at OSCON last week, they said that it probably > wouldn't be free for us, since they're in the business of selling this > service, > and generally won't be offering free service to projects that are mainly > driven > by a single company which they make money off of, and should thus be able to > afford a commercial license.
Could we offer them a free copy of the source, maybe 90% of the profit ... :) We (one of you, not me) can make a 'formal' application (with whoever's approval - someone at Sun?) and if they say no it's only an hour wasted ... > I'd love to see us find some way to get Coverity scans of OpenSolaris code, > but I think Sun's going to have to put money in for that. Doesn't seem fair. Can you ask if there is a budget for it ? (so if it is not free you might offer to pay). > Kyle wrote: > I don' t know for sure, but Coverity's competitor KlokWork > (www.klocwork.com) probably also does Opensource scans, and might be > willing to scan a project that Coverity had rejected. Personally I > prefer KlocWork, but really any static analysis is better than none. TWO (or three) heads are better than one (unless it's on my body or I turn into a Hydra). Any (quality) scanner that uses someone else's CPU to scan OpenSolaris and provides a neat interface that a small group of people can use to submit cleaned up reports to http://defect.opensolaris.org/ is better than not knowing. > James Carlson wrote: > On the plus side, there are nuggets of gold buried in the voluminous > reports generated. The question is whether you want to invest your > time and money into eyeballing those (and teaching all developers how > to cope with slow run times and complicated output), or put more > effort into traditional design and code reviews. We don't need to give "all" developers access. Ask for volunteers and then a few of the core Sun OpenSolaris developers can pick a half dozen people and assign them to that group. As for the "run times" it does not run on _our_ computers is my understanding. > put more effort into traditional design and code reviews. Good plan. Pick a half dozen people (volunteers) and ask them to go through the code. Have them send an email to the code's "owner" - "fix it or I will" and simply create "fix patches" that _we_ can apply (and the "owner" (origonator) can look at) so that lint is clean. This sort of thing happens over at linux and gcc -- but they have a larger user base in the bugzilla. > It's also worth mentioning that we're not yet getting the most that we > can out of lint. In a nightly run with lint enabled, it runs with > just the default 'level' flag. Turn it up (on your runs, not in the distributed source). I'm in the middle of compiling gcc 4.x (with ALL features and languages working) and am going to try compiling OpenSolaris with that as the "default compiler" and Sun Studio 12 as the "shadow compiler" - should be fun. I already found one 'bug' (mistake) in SX:CE - /usr/bin/gdb was compiled 32 bit ! There was an announcement (I noticed not long ago in another thread) that Sun had a server farm sitting around waiting for someone to submit a proposal of what to use it for. Ask if we can "borrow" it while it's final use is being decided ... > Jörg wrote: > If you like to scan Solaris ON and work on the results, this would take > probably one man year. With a half dozen volunteers it might take one quarter the time. We might get a few dozen people interested. > Alan Coopersmith wrote: > Another project I saw at OSCON is Mozilla's static analysis tools ... The more the merrier. Lets see how many volunteers we get, figure out which tools we want to use and how to divide things up. Once we pull out most of the weeds the rest of the garden will be easier to maintain. Rob This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
