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

[James Porter]

On Fri, 2011-06-10 at 21:21 +0200, Jed Brown wrote:
> On Fri, Jun 10, 2011 at 21:14, James Porter <jvporter at wisc.edu> wrote:
>         That's not what your patch does, though. I think this sounds
>         like a good
>         idea in general (I missed the first email that explained the
>         context),
>         but I don't think "never allocate for 0-sized arrays" is the
>         right way.
>         
> 
> 
> Ah, but it is equivalent. If the user nullified the pointer, then by
> definition, they already have a pointer equal to NULL. That is valid
> to be passed to free(). If the user had a pointer that was non-NULL,
> then (according to our "new" semantics) they didn't want you to
> allocate anything.

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.

> I can't imagine a use case where the caller would depend on malloc(0)
> actually being called (given that either way, they have a pointer that
> can be free'd).

Sorry, I should have been clearer; I'm including "leave the array
pointer as NULL" under the umbrella of "allocation", since it gives you
an "array" that lets you do what you'd expect with it: iterate over it
and free it.