[llvm-dev] [cfe-dev] Before we go cleaning up LLVM+Clang of all Static Analyzer Warnings...

Yury Gribov via llvm-dev llvm-dev at lists.llvm.org
Fri May 6 03:02:06 PDT 2016

On 05/05/2016 10:42 PM, David Blaikie via cfe-dev wrote:
> On Thu, May 5, 2016 at 11:50 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>> On May 5, 2016, at 11:20 AM, David Blaikie via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>> Hi Apelete,
>>> Thanks for trying to help cleanup the LLVM codebase of Clang Static
>> Analyzer warnings.
>>> But it seems a lot of the fixes that are being proposed are somewhat
>> mechanical and may be doing the wrong thing in a few ways.
>>> * Initializing variables that are only used when initialized through
>> some existing codepath - this can make tools like Memory Sanitizer less
>> useful, because now the value is initialized even in some path where that
>> value is never intended to be used
>>> * Adding assertions for pointers that are known to be non-null - in some
>> cases this is helpful, when the algorithm that ensures the non-null-ness is
>> sufficiently opaque. But for function parameters - we have /lots/ of
>> non-null function parameters. I think it'd be impractical to assert on all
>> of them.
>> Any reason we don't use more references? I like references because when I
>> read code it is very clear that the argument *can't* be null and I don't
>> have to think if I need to handle the null case.
>> When I made the DataLayout "mandatory" on the Module last year, I moved
>> every single use of the DataLayout to be a reference, and this helped to
>> remove each and every places that were null-checking the DL.
> I'm a big fan of references as well - but there's still some (read: a lot
> of) community/codebase momentum behind certain entities being referenced by
> pointer because their pointer identity is so intrinsic to their nature
> (comparing instruction pointers, etc). Not that one can't take the address
> of a thing and compare it, stuff it in a container, etc.

Note that Chris didn't have very positive experience with agressive use 
of references in LLVM APIs: 

> - Dave
>> --
>> Mehdi
>>> But if we want to do something like this we should probably have some
>> community discussion about how how to go about any of these things across
>> the codebase. Maybe using nonnull attributes would be a better approach to
>> the parameter issue, for example - but it'll still be a lot of code churn
>> that there should probably be general consensus on rather than approaching
>> it piecemeal with reviewers in different parts of the codebase.
>>> Thanks,
>>> - Dave
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

More information about the llvm-dev mailing list