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

[Mark Miller]

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?

Or, are you discussing an IBASE_SUCCESS case where no allocation is
performed because the implementation's answer is zero things? If its
this case, then I think implementation is required to set occupied size
to zero and should also be required to set returned pointer to zero
(NULL) as well.

Mark



On Fri, 2011-06-10 at 11:30, Jed Brown wrote:
> On Fri, Jun 10, 2011 at 20:16, James Porter <jvporter at wisc.edu> wrote:
>         A null pointer can *always* be freed. It's just a no-op.
> 
> Correct (not a no-op, it tests the pointer and returns), but the
> problem is what happens if the implementation does not write anything
> into that pointer.
> 
> Suppose you pass in an undefined/stale array pointer and set the
> allocated size to 0. If the implementation finds that the expected
> length is actually zero, should it still set your pointer? I think it
> should not because the caller would have to put an if statement around
> every call that might handle zero-length arrays.
> 
> But if that's what happens, then the caller who was expecting the
> library to allocate must know not to free the pointer (because it's
> still undefined/stale). Or the caller initializes the pointer to NULL
> before passing it in. This is my preference because it makes the
> resource management intent clear from a local reading of the source.
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511