[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