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

[David Blaikie via llvm-dev]

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.

- 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/11ada551/attachment.html>