[petsc-dev] clang --analyze messages on PETSc

[Matthew Knepley]

On Tue, Apr 14, 2015 at 6:00 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> > On Apr 14, 2015, at 5:40 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> > Matthew Knepley <knepley at gmail.com> writes:
> >> I really do not want that. I am especially unwilling to do that just to
> >> appease static analysis.
> >
> > I think it's actually better for debuggability and
> > strictness/normalization within the code, but we had this argument a
> > year ago and if you still insist, I'm not going to dig it up.
>
>   But I did. So Matt's argument is that having a pointer you are not
> allowed to use be anything but NULL is dangerous because it could be used
> wrong and no one would know.
>
>    BTW how come all the code  (!(m1) ? (*(r1) = 0,0) : 0)  stuff uses 0
> instead of NULL? Wouldn't it be clearer to use NULL when one means NULL?


I am arguing for uniformity. With the current system, all internal PETSc
mallocs (we are supposed to use PetscMallocK everywhere)
will return NULL for 0 size argument. On the other hand, if you just
forward the request to malloc, the standard says it can return
a valid pointer OR NULL, so now we have different behavior. What is worse
is that this "valid" pointer can be freed, but it cannot
be dereferenced, and there is no way to determine that it cannot be
dereferenced, unlike NULL. I see absolutely no good argument
for this situation.

   Matt


>
>   Barry
>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150414/d0519f57/attachment.html>