On Jan 30, 2014, at 1:55 PM, Matthew Knepley <[email protected]> wrote:

> On Thu, Jan 30, 2014 at 1:53 PM, Barry Smith <[email protected]> wrote:
> 
> On Jan 30, 2014, at 12:46 PM, Brad Aagaard <[email protected]> wrote:
> 
> > On 01/30/2014 10:34 AM, Jed Brown wrote:
> >> Brad Aagaard <[email protected]> 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

   I don’t see how this can possibly work

#if defined(PETSC_USE_DEBUG)
#define PetscFree2(m1,m2)   (PetscFree(m2) || PetscFree(m1))
#else
#define PetscFree2(m1,m2)   ((m2)=0, PetscFree(m1))
#endif

  You need to free the first m[i] that is not null. If m1 was null in the 
optimized form you never free anything.

   These macros are getting horrible, can they become something cleaner?


   Barry

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

Reply via email to