[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 16:00:10 CDT 2011
On Fri, Jun 10, 2011 at 22:03, James Porter <jvporter at wisc.edu> wrote:
> It's close, but not quite equivalent. What I'm suggesting is that we
> also remove the "alloc=0" means "allocate for me" behavior entirely. The
> current patch will allocate a new array when alloc=0, array=non-NULL,
> and count>0, but I think it should error out, since:
>
> 1) it simplifies the semantics of the arguments (alloc no longer has a
> special value to invoke "allocate for me" behavior)
> 2) it guarantees that no matter how you specify "allocate for me", that
> you have a usable array on return (i.e. you can loop over it and
> free() it) because there's only one way to specify that.
>
> Essentially, if array=NULL, iMesh should be able to totally ignore the
> alloc parameter. Granted, like your patch, this requires callers to
> change how they initialize their arrays, but I don't think there's a way
> around that.
>
Okay, I also prefer these stricter semantics, but it's a much bigger API
change so it can't be done as casually.
Here is the proposed logic table:
case array alloc actual Allocation Result
--------------------------------------------------------------
A NULL 0 0 no success
B NULL 0 1+ yes success
C NULL 1+ 0 no success
D NULL 1+ 1+ no ? [1]
E valid 0 0 no [2] success
F valid 0 1+ no failure [3]
G valid 1+ 0 no success
H valid 1+ 1+ no success
[1] If you don't allocate, then either SEGV or iBase_BAD_ARRAY_SIZE. Note
that you can't actually distinguish a NULL pointer from an invalid pointer
(via malloc(0) or otherwise). An error here is just being polite, but the
check would be optional for a conforming implementation. Are you suggesting
to allocate and succeeed here? That would be more lenient. I don't have a
strong rationale either way.
[2] This is the case my patch was concerned with.
[3] This is your suggestion, which I endorse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/5732e140/attachment.htm>
More information about the moab-dev
mailing list