Gimpel, makers of PC-Lint, have a nifty web form where you can submit a chunk of code and see the PC-Lint output. I decided to see what its limits are by running some of the bugreport test cases through.

---

First, let me say that I love PC-Lint. It puts most of the commercial code analyzers to shame with its inter-function value tracking and powerful configuration and customization features. It's also really cheap -- I bought my own personal copy about 6 years ago and have used it quite a bit in my professional and personal (open source) C and C++ programming. I have a config file for it I've built up over the years of tuning it for various projects. Their support is pretty good, and for things they can fix easily they are decently responsive (1-2 weeks). Recently, Gimpel has put up a web form that demonstrates PC-Lint by running it on a snippet of code you paste into the form. I used the web form, and the latest beta patch (8.00u6) to test these cases.

bugreport 's C test cases that I wrote are broken up into simple, medium, and hard. At first, I tried the medium test cases, but PC-Lint didn't find the bugs in any of them, which was surprising (I got it to work eventually -- read on). I've posted a link to this post on their support forum, hopefully it's a simple fix for some of them and it'll make it into their next beta patch and release.

First, I tried the most simple -- it allocates a buffer and writes a 0 one beyond the end of the allocated buffer. PC-Lint had no serious trouble with this:

        ((char *)p)[16] = 0;
..\src\bugreport\tests\simple\heap\simple-malloc-via-immediate-oob.c  6
    Warning 661: Possible access of out-of-bounds pointer (1 beyond end of
    data) by operator '[' [Reference: file ..\src\bugreport\tests\simple\heap\simple-malloc-via-immediate-oob.c:
    lines 5, 6]

When I say no *serious* trouble I mean that it complains about the standard GCC headers quite a bit, even when I supply -cgnu and use the latest co-gnu3.lnt or co-gnu.lnt configuration files. This is on KUbuntu 6.06 with GCC 4.0.3, which is pretty common, so I hope they fix that up a bit soon. A workaround is to download the ANSI headers that Gimpel provides and include them (via the -i option) before your other include paths. That also works around the header parsing issues mentioned below, making the results match the web demo more closely.

The next simple test I tried involved a global variable:

#include <stdlib.h>

static const size_t size = 16;

int main(int argc, char **argv)
{
        void *p = malloc(size);
        ((char *)p)[16] = 0;
}

Strangely, the on-line version detected the bug alright, but 8.00u6 did not. It looks like 8.00u6 got confused about the static size_t, maybe related to the header warnings I was seeing:

static const size_t size = 16;
..\src\bugreport\tests\simple\heap\simple-malloc-via-global-oob.c  3  Warning
    401: symbol 'size_t' not previously declared static at location unknown
..\src\bugreport\tests\simple\heap\simple-malloc-via-global-oob.c  3  Error 10:
    Expecting ';'
                         _
        void *p = malloc(size);
..\src\bugreport\tests\simple\heap\simple-malloc-via-global-oob.c  7  Error 40:
    Undeclared identifier 'size'

The next variation is allocating the size via a heap buffer:

#include <stdlib.h>

int main(int argc, char **argv)
{
        size_t *size = malloc(sizeof(size_t));
        *size = 16;
        void *p = malloc(*size);
        ((char *)p)[16] = 0;
}

Unfortunately, the online version didn't detect the out-of-bounds access and the 8.00u6 got stuck on not knowing size_t again due to parsing errors in the GCC headers:

        size_t *size = malloc(sizeof(size_t));
..\src\bugreport\tests\simple\heap\simple-malloc-via-heap-oob.c  5  Error 40:
    Undeclared identifier 'size_t'
..\src\bugreport\tests\simple\heap\simple-malloc-via-heap-oob.c  5  Error 40:
    Undeclared identifier 'size'
..\src\bugreport\tests\simple\heap\simple-malloc-via-heap-oob.c  5  Error 40:
    Undeclared identifier 'size_t'
..\src\bugreport\tests\simple\heap\simple-malloc-via-heap-oob.c  5  Error 63:
    Expected an lvalue

It appears as though they don't track concrete values stored in heap-allocated buffers. This is understandable, as the memory requirements would be larger, but I would personally prefer they have a configurable option where the individual values are tracked if the buffer is below a certain size. In this case, the Simplest Thing That Could Possible Work would be to only track the value in first element of the buffer.

Just for grins, I played with the medium difficulty inter-function system tests to try to tickle PC-Lint into detecting them:

#include <stdlib.h>

void bug(size_t size)
{
        int *array = malloc(size);
        array[0] = 0;
}

int main(int argc, char **argv)
{
        ////<bug />
        bug(0);
}

It looks like PC-Lint just doesn't like malloc(0), but doesn't complain about it. It just causes it to miss the bugs in the code. If I change the code slightly to this:

#include <stdlib.h>

void bug(size_t size)
{
        int *array = malloc(size);
        array[4] = 0;
}

int main(int argc, char **argv)
{
        ////<bug />
        bug(4);
}

Then PC-Lint detects it properly after two passes:

  File ..\src\bugreport\tests\medium\interfunction-immediate-parameter.c line
    12: bug(4)
..\src\bugreport\tests\medium\interfunction-immediate-parameter.c  6  Warning
    662: Possible creation of out-of-bounds pointer (4 beyond end of data) by
    operator '[' [Reference: file ..\src\bugreport\tests\medium\interfunction-immediate-parameter.c:
    lines 5, 6, 12]

However, PC-Lint doesn't detect bugs in the the medium difficulty branch-based tests. On the up side, there's no parse errors either.

Overall, PC-Lint does a pretty good job but I don't think most users would have figured out how to tickle it to get more optimal results. I'm a long-time user, and have written static analysis products in the past, so I have some instincts about how to figure out where the seams are. Hopefully Gimpel can take this blog post and the test cases, fix the bugs for their next release, and continue their long tradition of trouncing competitors who cost several orders of magnitude more for significantly less real-world bug-finding capability.

Discussion: showing all 0 messages

(No messages)

>

Post a new message:

---