Static analyzer

Hi,

I'm currently playing with the static analyzer. It looks very nice, it found a few leaks already. Two comments:

1. It would be very useful to me if the file name of the reports could include the (beginning of) the original file name. When I'm looking at the reports in Safari, I could then simply look at the URL bar to see which file the current report is for.

2. The project I'm checking contains several sections that look like this:

     const void *bytes = [data bytes];
     int rows = *((int*)bytes); bytes += sizeof(int);

scan_build complains in these cases that "Value stored to 'bytes' is never read".

Nico

Hi,

I'm currently playing with the static analyzer. It looks very nice, it
found a few leaks already. Two comments:

1. It would be very useful to me if the file name of the reports could
include the (beginning of) the original file name. When I'm looking at
the reports in Safari, I could then simply look at the URL bar to see
which file the current report is for.

Hi Nico,

Today I committed a patch that puts the name of the file with the bug in the title of the report page:

   http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006407.html

This patch should now be available in checker-58 (for those using the prebuilt binaries for Mac OS X).

We can also potentially include a fragment of the original source file name in the name of the report-XXX.html file as well. I'm not certain if that is necessary given the patch I mentioned. What do you think? I'm fine with making the change if you feel it would make the tool easier to use.

2. The project I'm checking contains several sections that look like
this:

    const void *bytes = [data bytes];
    int rows = *((int*)bytes); bytes += sizeof(int);

scan_build complains in these cases that "Value stored to 'bytes' is
never read".

I mocked up a test case, but I couldn't really reproduce this error. If it is no trouble, can you file a Bugzilla report with a reduced test case that exhibits the problem? Filing a Bugzilla report also ensures that a fix eventually goes in, as requests for changes have started queuing up and I don't want to forget this one.

Thanks for the feedback!

Ted

Hi,

1. It would be very useful to me if the file name of the reports could
include the (beginning of) the original file name. When I'm looking at
the reports in Safari, I could then simply look at the URL bar to see
which file the current report is for.

Today I committed a patch that puts the name of the file with the bug in the title of the report page:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006407.html

This patch should now be available in checker-58 (for those using the prebuilt binaries for Mac OS X).

We can also potentially include a fragment of the original source file name in the name of the report-XXX.html file as well. I'm not certain if that is necessary given the patch I mentioned. What do you think? I'm fine with making the change if you feel it would make the tool easier to use.

that change is sufficient in my eyes. Thanks :slight_smile:

2. The project I'm checking contains several sections that look like
this:

   const void *bytes = [data bytes];
   int rows = *((int*)bytes); bytes += sizeof(int);

scan_build complains in these cases that "Value stored to 'bytes' is
never read".

I mocked up a test case, but I couldn't really reproduce this error. If it is no trouble, can you file a Bugzilla report with a reduced test case that exhibits the problem? Filing a Bugzilla report also ensures that a fix eventually goes in, as requests for changes have started queuing up and I don't want to forget this one.

Done: 2528 – False positive "dead store" for aliased pointer

Nico

Thanks for filing the bug report. My belief is that the checker is doing the right thing. The warning has to do with the “+=” operation to bytes, not the store to rows. The “+=” increment is essentially:

bytes = bytes + sizeof(int);

The checker is saying that the new value stored to bytes is never used (and in your test case, it isn’t).

Could it be the case that the test case doesn’t capture the issues that you are seeing?

Ted