Re: Coverity Open Source Defect Scan of Firefox
Jon Smirl
Project Defects Original# Lines of Code Defects / KLOC
Firefox 50 108 310,152 0.161
The Mozilla source tree on my machine has 4.2M lines of code in it.
Some of that is test code, but that's a long ways from 310K lines. Are
you including all of the XPCOM components Firefox uses? What about the
different platforms?
--
Jon Smirl
jons...@gmail.com
Dan Veditz
> What are you scanning for FIrefox?
> Project Defects Original# Lines of Code Defects / KLOC
> Firefox 50 108 310,152 0.161
>
> The Mozilla source tree on my machine has 4.2M lines of code in it.
> Some of that is test code, but that's a long ways from 310K lines.
They exclude blank and comment lines, and of course don't count all the
chrome, so it'll always be lower than raw "wc" output. They do seem to
have missed all the .cpp files, though. I get just under 2M lines of
c/c++ code in my tree the way they count it.
Jon Smirl
Another measure that something is really messed up:
PostgreSQL 294 295 816,856 0.360
RPM is 2.94MB
ethereal 13 143 1,165,664 0.011
RPM is 7.86MB
Firefox 50 108 310,270 0.161
RPM is 17.53MB
Ratio is about 6.8 bytes per line, that implies Firefox should have
2.6M lines of code.
If this is going to be done right all of the system libraries that
Firefox uses need to be scanned too. They're getting $1M of DHS tax
money to do this so I hope they do a thorough job.
--
Jon Smirl
jons...@gmail.com
Andrew Schultz
> Firefox 50 108 310,270 0.161
> RPM is 17.53MB
>
> Ratio is about 6.8 bytes per line, that implies Firefox should have
> 2.6M lines of code.
An RPM contains compressed binaries (and data files). What does its
size have to do with bytes of source code?
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Jon Smirl
> Jon Smirl wrote:
> > Firefox 50 108 310,270 0.161
> > RPM is 17.53MB
> >
> > Ratio is about 6.8 bytes per line, that implies Firefox should have
> > 2.6M lines of code.
>
> An RPM contains compressed binaries (and data files). What does its
> size have to do with bytes of source code?
Most of the RPM is binary, it is a good proxy for the code size. There
is a fairly constant ratio of binary to source produced by the
compiler. The point is show that 310K lines of source code does not
correspond to a 17.5MB RPM unless the Firefox RPM contains about 15MB
of documentation which it doesn't. If you want to expand the rpms and
check only the binary files I think you'll find the estimates aren't
that far off.
The main problem is that Coverity is saying Firefox only has 310K
lines of code when the right number is in the 2-2.5M range. That means
they haven't checked 90% of the Firefox code for problems. Plus the
2-2.5M number is just Firefox, all of the system libraries need to be
included too and they probably add another 1-1.5M lines.
--
Jon Smirl
jons...@gmail.com
Andrew Schultz
> On 3/22/06, Andrew Schultz <ajsc...@verizon.net> wrote:
>> Jon Smirl wrote:
>>> Firefox 50 108 310,270 0.161
>>> RPM is 17.53MB
>>>
>>> Ratio is about 6.8 bytes per line, that implies Firefox should have
>>> 2.6M lines of code.
>> An RPM contains compressed binaries (and data files). What does its
>> size have to do with bytes of source code?
>
> Most of the RPM is binary, it is a good proxy for the code size. There
> is a fairly constant ratio of binary to source produced by the
> compiler. The point is show that 310K lines of source code does not
> correspond to a 17.5MB RPM unless the Firefox RPM contains about 15MB
> of documentation which it doesn't. If you want to expand the rpms and
> check only the binary files I think you'll find the estimates aren't
> that far off.
Actually, I'm guessing you're comparing the Fedora/Red Hat-shipped RPM.
It includes all localizations, roughly doubling the size.
Which brings me back to... why are you trying to relate compressed
binary + data size to # of source code lines? When you have the source!
Jon Smirl
Using the source directly is overstating the KLOC numbers since there
is no simple way to separate out test code and code that is in the
tree but not shipping.
I see now that 17.5M is too big, 8.5MB is more accurate. That moves
the estimates down to the 1.5-2M range which agrees with Dan's
numbers.
This makes me wonder how Microsoft can build their new Vista graphics
toolkit in 6-800K as claimed.
http://news.com.com/Vista%20graphics%20tools%20to%20reach%20Mac,%20phones/2100-1016_3-6052021.html?tag=nefd.top
http://ajaxian.com/archives/microsofts-mix-06-conference
>
> --
> Andrew Schultz
> ajsc...@verizon.net
> http://www.sens.buffalo.edu/~ajs42/
> _______________________________________________
> dev-general mailing list
> dev-g...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-general
>
--
Jon Smirl
jons...@gmail.com
Jon Smirl
Using the source directly is overstating the KLOC numbers since there
is no simple way to separate out test code and code that is in the
tree but not shipping.
I see now that 17.5M is too big, 8.5MB is more accurate. That moves
the estimates down to the 1.5-2M range which agrees with Dan's
numbers.
This makes me wonder how Microsoft can build their new Vista graphics
toolkit in 6-800K as claimed.
http://news.com.com/Vista%20graphics%20tools%20to%20reach%20Mac,%20phones/2100-1016_3-6052021.html?tag=nefd.top
http://ajaxian.com/archives/microsofts-mix-06-conference
>
> --
> Andrew Schultz
> ajsc...@verizon.net
> http://www.sens.buffalo.edu/~ajs42/
Dan Veditz
> What are you scanning for FIrefox?
> Project Defects Original# Lines of Code Defects / KLOC
> Firefox 50 108 310,152 0.161
>
> The Mozilla source tree on my machine has 4.2M lines of code in it.
> Some of that is test code, but that's a long ways from 310K lines.
They exclude blank and comment lines, and of course don't count all the
Ben Chelf
> If this is going to be done right all of the system libraries that
> Firefox uses need to be scanned too. They're getting $1M of DHS tax
> money to do this so I hope they do a thorough job.
>
Just so it's clear to folks on the list, we're now aware of some work
that needs to be done to make the build/analysis of Firefox more
complete. Rest assured that we are doing the best we can to work with
the appropriate folks to make sure that we are analyzing the whole of
the project. Stay tuned for updates ... thanks for your patience.
-ben