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

[Barry Smith]

> On Apr 14, 2015, at 6:13 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> 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 understand what you wrote below. My question is why there are a bunch of symbols 0 in the PetscMalloc() macros; shouldn't they be NULL for clarity.

    0.0  for float, 0 for integer, and NULL for pointer?  That's all.

> 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