> On Apr 14, 2015, at 6:13 PM, Matthew Knepley <knep...@gmail.com> wrote:
>
> On Tue, Apr 14, 2015 at 6:00 PM, Barry Smith <bsm...@mcs.anl.gov> wrote:
>
> > On Apr 14, 2015, at 5:40 PM, Jed Brown <j...@jedbrown.org> wrote:
> >
> > Matthew Knepley <knep...@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
