[petsc-dev] PetscMalloc for size zero

[Barry Smith]

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

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>> On Jan 30, 2014, at 3:00 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>>    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).
> 
> True, but an array length is needed anyway and any references to that
> pointer can still be detected by the memory checker.  Also, if someone
> really wants to get NULL (or a special value), we can use a malloc
> implementation that does so.  (We can add a runtime option for this if
> someone wants it for debugging.)
> 
>>   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.
> 
> Fair, but you'll have as much trouble doing anything with that code.
> 
>>   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. 
> 
> Is this a problem actually encountered in practice?
> 
>>    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.
> 
> We can't make them functions because we use the type sizes and pass
> __FILE__, __LINE__.  I'm not motivated to change this unless someone
> demonstrates that this is a non-theoretical problem.

  No one is asking YOU to change this. I would be happy if it was reworked using function calls (obviously with a macro wrapper) that made all the decisions (debug or not etc) runtime rather than compile time and had much more robust error checking, then adding a NULL on 0 feature would be a trivial addition.

  Note that currently when running optimized with valgrind; valgrind only sees the one_big_malloc so can miss lots of overwrite and underwrites within the chunks malloced. By making everything runtime we can let valgrind have more information and manage correctness of each sub chunk.


  Barry