[Dev] Prevent static analysis for Tizen 3.0

Carsten Haitzler c.haitzler at samsung.com
Fri Dec 13 03:11:37 GMT 2013

i can't say for tizen 3 or prevent, as tizen is in a bit of a strange 
position. it is both a distribution AND a duplicate of upstream projects 
AND a set of independently developed software projects... but upstream 
EFL has our trees for efl, elementary and enlightenment registered with 
coverity scan (for about 6 months now). coverity allows any open source 
project to apply to hav e them scan the project code for free (they do 
it once per day and you can register a git tree that they will update from).

according to coverity, industry standard for "good quality commercial 
code" is 1.0 coverity found bugs per 1000 lines of code. the linux 
kernel comes in at about 0.6 or so (depending on version). postgresql 
was about 0.2. open source projects shows better average code quality 
than commercial projects. as commercial projects became bigger their 
quality went down (issues per 1000 lines of code went up - thus as a 
precentage of code size, bugs increased faster than code size did). open 
source projects show the reverse trend. as they get bigger, their 
quality increases (issues per 1000 lines of code goes down).

we've been using coverity to improve efl codebase quality. currently our 
bugs per 1000 lines of code are:

efl: 0.60
elementary: 0.11
enlightenment: 0.66

these numbers have been steadily going down over the past 6 months as 
we've gone over the coverity reports and nuked the issues they do find. 
we've also been using clang's static analysis too. we are also fairly 
religious about keeping the code gcc "warning free" (given a relatively 
noisy set of warning flags like -W -Wall -Wextra -Wno-shadow 
-Wno-unused-but-set-parameter). it's a bad idea to use just one tool. so 
even if you don't see prevent output, there are other options to look at 
for automatid quality checking tools.

we'd like to see out issue densities get to as close to 0 as possible. 
:) i know that coverity scanning is not finding the kinds of bugs that 
are "i press button and it doesnt do what it should" kind of bugs, but 
they do hunt down often the "very rare and mostly invisible" bugs that 
happen in bizarre code paths that are hard to reproduce  and may be the 
"happens only once" kind of bug reports. the advantage is that coverity 
provide a REALLY good indicator of where the bug is and a trace of why 
it happens. it's far less obscure than clang reports. clan is free+open 
and can only help in improving quality. many things clang finds are 
things coverity (and prevent) look for too. look at 
for example (we run nightly clang reports too on upstream code).

if the code you work on is an open source project with an upstream, 
consider registering for a free coverity scan. they have a web ui for 
going through the issues etc. etc. which is not that bad at all (it's 
pretty good actually). reality is that if the upstream project is then 
used in tizen, tizen totally benefits from the better code quality right 
out of the box. and you can use clang today for free to do the same.

On 12/12/2013 09:06 PM, Nikita Kalyazin wrote:
> Hello,
> As far as I know, there was some automatic Prevent check for Tizen 2.1 projects.
> Does such a service exist for Tizen 3.0? If so, what is the subscription procedure for that?
> Thank you.

The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131213/711a2a1d/attachment.html>

More information about the Dev mailing list