[petsc-dev] PetscMalloc for size zero

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>> Why do we want this behavior?
>
>    Matt feels that having zero space allocated items always as NULL is
>    useful. Perhaps as a debugging/error determining issue since no one
>    can “accidentally” use the location returned by malloc(0) and in
>    the debugger one won’t mistakenly think that a pointer which
>    contains something returned by malloc(0) has a legitimate value in
>    it.

The pointer returned by malloc(0) [e.g., optimized mode] is actually
invalid.  PETSc checks in debug mode; valgrind tracks zero-size
allocations.

>> Can we see some concrete code that is affected by this behavior?  We
>> needed PetscMalloc[2-7] to work in optimized mode, so nothing in
>> PETSc should be depending on it.
>
>    What does “it” here refer to?  And what do you mean by “depending
>    on”.  Certainly we could make PetscMallocn() and PetscFreen()
>    behave in a way Matt suggests even in optimized code (if we choose
>    to).

I'm assuming that current code is correct, thus I'm asking where
significant simplifications would occur if the caller knew that
zero-sized arrays were NULL.

>    Some notes:
>
>    We currently mark freed pointers with a NULL so they cannot be
>    accidentally used at a later time.
>
>    In Jed’s model something a “zero length space” will have the value
>    NULL and something not. There is, AFAIK, no tool to check the
>    address and see if it is a real pointer or a pointer to an invalid
>    location.

There's no tool to determine whether it can hold more than one entry.
What arrays do we have that (a) do not store size and (b) do not use a
mandatory end marker like '\0' (in which case you had to allocate the
end marker)?

>    With Matt’s scheme we could also mark “zero length space” with a
>    NULL. In an ideal world I could see having a different specific
>    value for “zero length space” such as INVALIDPOINTER then one could
>    distinguish the two values and their different meanings.  Alias I
>    don’t control the ideal C world.

Why don't you have this information out-of-band anyway?

>    I agree with Jed that we don’t want any PETSc code to be dependent
>    on PetscMallocn(0) always being NULL in all cases; but I understand
>    Matt’s argument that having PetscMallocn() always being NULL makes
>    debugging easier.

I'm not convinced of this.  Memory checkers will notice accesses (and be
able to track back to where the zero-length array was "allocated").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140130/7f0b8962/attachment.sig>