[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 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. They call the function, the
implementation also computes that zero items are to be returned. All good,
but what should the implementation do with the pointer? Regardless of what
it does, it's not valid to dereference. But the caller's code knows that
(e.g. their loop will run for zero iterations) without any special if
statements.

With the current semantics, the pointer is zerod (or set to whatever
malloc(0) returns). This is BAD because you just overwrote the caller's
pointer that used to point to a zero-length segment of their own array.

I want the implementation to leave the pointer alone.

The only case where this change is not backward-compatible is if the user
wanted the implementation to allocate, did not initialize the pointer,
passed in alloc=0, and then called free(ptr) without checking. There is a
trivial fix for this: set ptr=0 before calling the function. I believe this
also makes the expected semantics more clear to the reader, thus making
their code easier to read.

There is no such easy fix for writing into the user's own allocated memory
with computed expected  length 0. The caller would have to handle the
zero-length case explicitly with an if statement. Yuck.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/dd7707d9/attachment.htm>