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