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

James Porter jvporter at wisc.edu
Fri Jun 10 13:59:09 CDT 2011


On Fri, 2011-06-10 at 20:44 +0200, Jed Brown wrote:
> On Fri, Jun 10, 2011 at 20:35, Mark Miller <miller86 at llnl.gov> wrote:
>         I could be totally off-topic here 'cause I haven't followed
>         this thread
>         in detail. However, my understanding is that no return
>         argument from
>         ITAPS interface should be trusted (e.g. read) if the returned
>         err code
>         (in all relevant API calls) is anything other than
>         IBASE_SUCCESS. Is
>         that the case you're discussing here?
>         
> 
> 
> We are discussing an iBase_SUCCESS case.
> 
> 
> In the use case I care about, the caller allocates their own memory
> and *calculates* an expected return length of zero.

Is your goal merely to make the function fail when the result would be a
non-empty array? I can't think of any other case where you'd be passing
in an alloc value of 0 and expect iMesh *not* to allocate for you.

In any case, a better spec would simply be "if you want iMesh to
allocate the array for you, pass NULL as the list pointer", (i.e. get
rid of the case where alloc=0 means "allocate the array for me"). I'm
not really sure why we need two ways to tell iMesh to allocate the array
for us.

- Jim




More information about the moab-dev mailing list