Re: Report on Coverity

On 25.10.2012 05:24, Alex Rousskov wrote:
> On 10/23/2012 08:28 PM, Amos Jeffries wrote:
>> On 22.10.2012 07:03, Kinkie wrote:
>>> Hi all,
>>> so far I have checked 134 defects uncovered by Coverity out of
>>> 334,
>>> I think I have seen enough to report some numbers.
>>> There are 49 false positives, and 24 intentional risky behaviors.
>>> 61 are bugs; but in most cases they are not real issues, just poor
>>> practice: things like undocumented assumptions on callers' handling
>>> of
>>> buffer sizes.
>>>
>>> I hope this can be enough help you understand whether Coverity is a
>>> good deal - triaging without fixing is a bit of a drag.
>>> The UI is nice but maybe due to me not sitting on the server it's
>>> not
>>> really as responsive as it could be.
>>
>>
>> I think we need to do one more thing along with this.
>>
>> We are not utilizing all the compiler warnings we could be which
>> might
>> find a lot of these problems without involving any further static
>> analysis than the build farm already provides. For example GCC
>> offers
>> -Weffc++ which will catch the constructor/destructor problems in our
>> practice vs policy.
>>
>> I'm doing a build of Squid with -Weffc++ -Wno-error=effc++ right now
>> to
>> produce a report for you to compare with Coverity issues of that
>> same type.
>
> Sounds good. We need to redo the test to enable similar checks in
> Coverity. For some strange reason, newer Coverity versions do not
> auto-enable some of those checks despite "--all" checks being used.
>
> Alex.

FYI: here is the bash script I am using for testing GCC 4.7.2 compiler
warnings.

Notice that I am only running at "default" build options. So there are
likely some more issues in other components which do not build on my
machine.

I follow up with a manual grep of the .ulog file to see what different
messages are and get a count for each one since various messages are
produced by each warning and our code may or may not have any particular
type of issue detected.

# Warnings which might be useful to enable on build-farm (or general
squid)
# but we need to analyse how many issues they highlight first.

# -Weffc++
# Bad C++ efficiency. Missing constructor/destructor operations or
definitions.

# -Wundef
# bad #if conditionals. We explicitly define Squid macros 0 or 1.
# should only be relevant for externally defined macros
# FIX: use defined(FOO) or !defined(FOO) instead of just (FOO)

# -Wshadow
# shadowed variables. should be none, but occasionally we still find
some casing bugs.

# -Wuseless-cast
# casting without changing the type
# FIX: remove the cast!

# -Wpadded -Wno-error=padded
# Optimization hint. Might be useful to reduce memory footprint in
places.
# But not always, so use only as a warning (ie append
-Wno-error=padded)

## PROCEDURE:

for x in effc++ undef shadow useless-cst padded ; do
   make distclean 1>/dev/null
   ./configure CXXFLAGS="-W${x} -Wno-error=${x}" --disable-translation
   touch includes/autoconf.h
   make 1>/dev/null 2>${x}-warnings.log

   # scan for all warning (first line only)
   # sort unique messages and produce initial count (may vary on manual
read later)
   grep -o -E "warning: .*" ${x}-warnings.log |
         grep -v "warning: " |
         sort -u > ${x}-warnings.ulog

   echo -n "SCAN: ${x} = "
   grep -c ":" ${x}-warnings.ulog
done

Amos
Received on Wed Oct 24 2012 - 21:47:59 MDT