Barry Smith <[email protected]> writes: > On Jan 30, 2014, at 3:00 PM, Jed Brown <[email protected]> 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.
pgpsUSFASX9MN.pgp
Description: PGP signature
