On Thu, Jan 30, 2014 at 1:53 PM, Barry Smith <bsmith@mcs.anl.gov> wrote:

On Jan 30, 2014, at 12:46 PM, Brad Aagaard <baagaard@usgs.gov> wrote:

> On 01/30/2014 10:34 AM, Jed Brown wrote:
>> Brad Aagaard <baagaard@usgs.gov> writes:
>>
>>> Matt and Jed,
>>>
>>> I see that Jed pushed some changes (jed/malloc-zero) for PetscMalloc to
>>> deal with memory alignment and a zero size. It looks like the pointer
>>> will NOT be NULL for a size of 0. Is this true?
>>
>> Yes, just like malloc(), it can be either a unique pointer or NULL.  You
>> need the size anyway to know how many elements are in the array.
>
> I thought it was a nice feature that PETSc improved on malloc() and free() by returning NULL for zero sized allocation (although this wasn't true for --with-debugging=0 due to memory alignment) and set pointers to NULL after freeing.

   With PetscMalloc() we could certainly return NULL on 0 mallocs but the code is a bit more involved  for the PetscMallocn() case.

   Here is what I suggestion. Someone suggest (i.e.. write) a refactorization of PetscMalloc(), PetscMallocn() that handles correctly any of the sizes being zero correctly in a branch and see how it goes.

I have pushed it. It looks simple to me

   Matt
 

   Barry


>
> What is the rationale for not returning NULL for mallocs of size zero other than conforming to C malloc behavior?
>
> Brad
>
>




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