<p dir="ltr">Interesting things. I want to dp my share of the clean up work. <br>
I guess I will learn a lot from that.</p>
<p dir="ltr">Will most of the issues be isolated to source files, or special functions or will it be more about keeping things conseqent over the whole code base?</p>
<p dir="ltr">/Nicklas</p>
<p dir="ltr">Skickat från min Sony Xperia™-smartphone</p>
<br><br>---- Even Rouault skrev ----<br><br>Le vendredi 06 mai 2016 10:55:50, Mark Cave-Ayland a écrit :<br>> On 05/05/16 19:06, Paul Ramsey wrote:<br>> > Hey Devs,<br>> > <br>> > Are we interested in receiving static analysis reports (Coverity) on<br>> > the PostGIS code base?<br>> > <br>> > The folks at CrunchyData are willing to stick-handle the bureaucracy<br>> > around getting Coverity account for the project and a system set up to<br>> > regularly pass the PostGIS code base through Coverity static analysis.<br>> > Coverity provides free (as in beer) accounts for open source projects,<br>> > so the actual Coverity "account" would be the PostGIS project's and<br>> > the PSC would control it.<br>> > <br>> > Anyways, other than providing an annoying list of things we should do<br>> > (gah!) I see no downside to having some more information on our code<br>> > cleanliness/security. Unlike the transifex stuff, there'd be no<br>> > dependencies on a foreign system, since if Coverity ever shut off our<br>> > access we'd be no worse off than we are right now.<br>> > <br>> > Thoughts?<br>> <br>> Definitely! I suspect that there will be a number of things to check<br>> after the first scan which may take some time. Note that Coverity does<br>> produce false positives, so perhaps some thought should be given to as<br>> to whether we should aim for a "clean" scan to the point where we can<br>> add annotations to the code for cases like these.<br><br>We have gone through the Coverity route for GDAL. Dealing with the results of <br>the first scan is likely to be painful (took months to clear the > 1300 initial <br>stock). There are some false positives, but not that much (10% ?). In general <br>you get false positives in portion of the code where the logic is convoluted <br>and you can get rid of most of them by simplifying the code a bit, or adding <br>extra conditions, and making it more obvious, including for humans. <br>For real false positives, you can add the following annotation before the line<br>/* coverity[name_of_the_violated_rule] */<br><br>The largest occurence in GDAL code base is /* coverity[tainted_data] */ , that <br>is due to using the value of an environment variable with no or little <br>checking. Likely not going to affect PostGIS.<br><br>We've also used Clang Static Analyzer. To be honest, it is far less powerful <br>than Coverity and has a high rate of false positives, and reworking the code <br>to make it happy can be really hard sometimes. It did uncover a couple of <br>things other tools didn't find though but the rate time invested to investigate <br>reports / bug founds is prettly low. If you want to give it a try, I'd <br>recommend only using it after cleaning all Coverity warnings, so as to limit <br>the number of things to look at.<br><br>-- <br>Spatialys - Geospatial professional services<br><a href="http://www.spatialys.com">http://www.spatialys.com</a><br>_______________________________________________<br>postgis-devel mailing list<br><a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br><br>