[cfe-dev] CLANG rpm packages, and hopefully a new project using scan-build

[Douglas Gregor]

Hello Stefan,

On Mar 10, 2009, at 1:19 PM, Stefan Reinauer wrote:

> Hi,
>
> from the web page:
>
>> Packaged builds for other platforms may eventually be provided,
>> but as the tool is in its early stages we are not actively promoting
>> releases yet. If you wish to help contribute regular builds of the
>> analyzer on other platforms, please email the Clang Developers'
>> mailing list.
>
> I started building snapshot builds of llvm + clang + scan-build for
> openSUSE at
> http://download.opensuse.org/repositories/home:/reinauer/
>
> Latest version available was r66512, right now it's building an r66542
> for testing.
>
> The reason we found interest in clang/llvm was the fine static code
> analysis tool scan-build.
>
> We started integrating scan-build in the build system of the open  
> source
> firmware (bios) project
> coreboot (formerly known as LinuxBIOS). Patrick Georgi made this first
> test run available:
>
> http://coreboot.org/~stepan/llvm/coreboot-builds/  (created with  
> r66542)

This is wonderful; thank you!

> There is one directory for each mainboard (target) that we support.  
> Feel
> free to have a look.
> Each target gets composed from a slightly different set of source  
> files,
> plus some generic
> ones, so each target reveals a different number of "bugs".
>
> We are still seeing a lot of "parser rejects" with our code, and I  
> would
> like to seek some help
> here to fix those (in clang or in our code, whatever is appropriate)

The best way to push along the process is to file a bug at http://lvm.org/bugs 
  with a small test case. Someone usually gets interested in fixing  
that bug and makes it happen. If there's an existing bug that looks  
like it covers the problem you're seeing, adding a "I'm seeing this  
too!" comment can help nudge things along.

> One issue I noticed is clang / scan-build does not seem to cope with
> forward declarations:
> ...
> note: forward declaration of 'struct pci_bus_operations'
> struct pci_bus_operations;
>       ^
> ...
> error: variable has incomplete type 'struct pci_bus_operations const'
> const struct pci_bus_operations pci_cf8_conf2;

Ah, yes. This is http://llvm.org/PR3310

And... uh oh... how'd that get assigned to me?

> Another one is that it won't detect when a function is never  
> supposed to
> return. We have a few situations in the code where we do the  
> following:
>
> void die(char * message)
> {
>    printf("ERROR: %s\n", message);
>    for (;;) ;
> }
>
> void somefunction(struct foo *param)
> {
>    if (!param)
>        die("param is not set!")
>
>    param->some_member = somevalue;
> }
>
> The above is errored as a potential NULL pointer dereference, which in
> fact it is not.

The analyzer knows about the "noreturn" attribute. I suggest changing  
die() like this

> void __attribute__((__noreturn__)) die (char * message)
> {
>    printf("ERROR: %s\n", message);
>    for (;;) ;
> }

so that the analyzer knows your intent not to return.

>
>
> We found quite a bunch more such things. If you are interested in  
> these
> types of reports, we will try to provide you as good information as
> possible.

Yes, we are definitely interested, and we try to be responsive to bug  
reports.

	- Doug