[MOAB-dev] [Itaps-users] [PATCH 1/2] iMesh_MOAB: do not allocate new memory for count=0 items

Jed Brown jed at 59A2.org
Fri Jun 10 13:30:39 CDT 2011


On Fri, Jun 10, 2011 at 20:16, James Porter <jvporter at wisc.edu> wrote:

> A null pointer can *always* be freed. It's just a no-op.


Correct (not a no-op, it tests the pointer and returns), but the problem is
what happens if the implementation does not write anything into that
pointer.

Suppose you pass in an undefined/stale array pointer and set the allocated
size to 0. If the implementation finds that the expected length is actually
zero, should it still set your pointer? I think it should not because the
caller would have to put an if statement around every call that might handle
zero-length arrays.

But if that's what happens, then the caller who was expecting the library to
allocate must know not to free the pointer (because it's still
undefined/stale). Or the caller initializes the pointer to NULL before
passing it in. This is my preference because it makes the resource
management intent clear from a local reading of the source.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/4a4cd39d/attachment.htm>


More information about the moab-dev mailing list