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

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:
> 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.

You have to store the size somewhere anyway and usually looping
constructs are empty if the array has length zero.  Guaranteeing NULL
means you can have logic like

  if (a) a[0] = 1;

or

  if (len) a[0] = 1;

If a could be non-NULL, then there is only one way to write the check
(and it encourages using logic constructs with fewer branches).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150414/9ccba4b3/attachment.sig>