[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:03:47 CDT 2011
On Fri, Jun 10, 2011 at 19:43, Tim Tautges <tautges at mcs.anl.gov> wrote:
> I'm fine with at least not allocating for count = 0, and my read of the
> iMesh spec is that it's silent on this issue.
It's subtle. The letter of the spec suggests (to me) that if you pass in
UNALLOCATED (currently defined using OR), you get a pointer that free() can
be called on. This pointer may or may not be NULL (some malloc()
implementations return NULL on zero-length allocation, others return a
pointer that can be freed). I doubt this was intentional; the zero length
case was probably not considered explicitly.
If nobody has a dependency on allocation of zero length returns, I think the
wording should just be clarified.
I think we (Jason & I) were for the OR instead of AND (i.e. allocating if
> either the allocated_length is 0 or the array ptr is NULL) just to avoid the
> nuisance of having to initialize more stuff. That's not a strong preference
> though.
I don't have a strong preference here, but memory allocation and ownership
is something that C programmers need to pay attention to. An extra "=0" is
not a great burden, especially if it improves semantic clarity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/64379c2d/attachment.htm>
More information about the moab-dev
mailing list