[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: RFC: Adding annotations to function declarations to improve
From:       "Rob Shearman" <robertshearman () gmail ! com>
Date:       2008-09-28 16:26:02
Message-ID: 1096648c0809280926t7526e833lfd98d8ff14a26b65 () mail ! gmail ! com
[Download RAW message or body]

2008/9/28 Reece Dunn <msclrhd@googlemail.com>:
> 2008/9/28 Rob Shearman <robertshearman@gmail.com>:
>> Hi all,
>>
>> This will be talked about in more detail at WineConf tomorrow, but I
>> just thought I'd throw this out there as a bit of background to any
>> discussions.
>>
>> Adding annotations to function declarations allows Prefast to pick up
>> certain classes of bugs with varying degrees of false positives. In
>> particular, with patches like the attached applied
>> byte-count/element-count mismatches can be detected with no false
>> positives and relatively few false positives for off-by-one errors and
>> other buffer overruns. Whilst this could be maintained outside of the
>> main Wine tree it would be more convenient in terms of automation of
>> Prefast runs if a vanilla Wine tree can be used (i.e. the annotation
>> patches are in the official tree).
>
> This is a good idea.
>
> Is it possible to make tools like sparse aware of these annotations? I
> know that the kernel devs use it to track kernel vs userland pointer
> mis-matches, but don't know that much about the details.

Making sure that kernel/user pointers are not mixed up is quite
different to the annotations that I am proposing to add. However,
someone could certainly hack on sparse to make it become a more
advanced static analysis tool.

> It should then be possible to allow users to configure (if not already
> available) the build to use sparse as the designated toolchain. This
> may also generate even more warnings, even without the annotations :).

While I have used sparse on individual source files before, I believe
it would be a challenge to configure allow it to be used from
makefiles.

-- 
Rob Shearman


[prev in list] [next in list] [prev in thread] [next in thread]