On Thu, Jan 30, 2014 at 12:50 PM, Matthew Knepley <[email protected]> wrote:
> On Thu, 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. >> >> What is the rationale for not returning NULL for mallocs of size zero >> other than conforming to C malloc behavior? > > > There is no such thing as "conforming to C malloc", since that WOULD allow > returning NULL in this case. > Actually, we are violating the malloc standard that Jed sent out. It says that for 0 size, malloc must return NULL or a unique pointer However, if we have PetscMalloc2(0,&r1,1,&r2) then r1 == r2 with the optimized implementation, and the pointers are not unique. Matt > I think we are doing users a disservice by not enforcing this. > > Matt > > >> >> 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 > -- 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
