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

[Yury Gribov via llvm-dev]

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: 
http://lists.llvm.org/pipermail/llvm-dev/2014-May/073193.html

> - 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
>