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

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Thu May 5 11:50:24 PDT 2016

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


> 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

More information about the llvm-dev mailing list