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