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

[Jed Brown]

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>