[MOAB-dev] [Itaps-users] [PATCH 1/2] iMesh_MOAB: do not allocate new memory for count=0 items
Tim Tautges
tautges at mcs.anl.gov
Fri Jun 10 13:22:02 CDT 2011
On 06/10/2011 01:03 PM, Jed Brown wrote:
> On Fri, Jun 10, 2011 at 19:43, Tim Tautges <tautges at mcs.anl.gov
> <mailto: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.
Ok, I didn't think of that. I think we should clarify the wording in the spec on that.
>
> 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.
I'd prefer to leave it as-is, though again not strongly. I'll put the question to itaps anyway, though. I'll also
change the implementation along the lines of your patch.
- tim
--
================================================================
"You will keep in perfect peace him whose mind is
steadfast, because he trusts in you." Isaiah 26:3
Tim Tautges Argonne National Laboratory
(tautges at mcs.anl.gov) (telecommuting from UW-Madison)
phone: (608) 263-8485 1500 Engineering Dr.
fax: (608) 263-4499 Madison, WI 53706
More information about the moab-dev
mailing list