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