[petsc-dev] PetscMalloc for size zero

[Barry Smith]

On Jan 30, 2014, at 3:00 PM, Jed Brown <jed at jedbrown.org> wrote:

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

    Yes, but in the debugger (or with a printf %p there is no portable way for a user to know that the pointer is invalid) whereas with NULL they would immediately know. A null pointer that leads to a segv conveys something different to someone debugging than some address where the user doesn’t know if that address came from a malloc(0) or some completely different way (like crazy pointer arithmetic).

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

   There would no know simplifications in the code; it would allegedly make debugging sometimes easier

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

   If you are trying to debug some code that you didn’t personally write (that may have been written by an idiot) it is rarely possible for you to know where this out-of-bound information is.

> 
>>   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”).

   We would obviously turn off all of this completely when running under valgrind to let valgrind do its thing.

    Side note; PetscMallocn() needs much more error checking: for example PetscMalloc2(-8,&x1,10,&x2) would not be detected as a problem but is problematic. Since we have to add all this error checking (likely by making these beasts functions) adding a return NULL on 0 won’t muck up the code much.

  Barry