Barry Smith <[email protected]> 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").
pgp2bLYHikLh9.pgp
Description: PGP signature
