[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:37, James Porter <jvporter at wisc.edu> wrote:

> I honestly can't think of any case where an undefined array pointer is
> "safer" than a null array pointer.
>

You are missing the point. We have two possible intents. One of them is
unexpressable with the current interface. They can be unambiguously
distinguished if the caller initializes a pointer that could have a
zero-length return and that they will call free() on.

We want to allow the user to fill a contiguous buffer with the contents of
multiple sets or with topological entities in a defined order, for example.

For this, they loop over the sets (perhaps much earlier in the code) and
compute the number of entities in each. Then they allocate one large array.
Then they loop over the sets and call iMesh_getEntities() or similar. The
pointer they pass in points at the offset in the contiguous array where they
want to place those entities. The allocated size may be computed as zero if
there are empty sets. They will compute the start of the next segment by
adding the size of this set to the
pointer.

iBase_EntityHandle *base,*p;
int i,total = 0;
for (i=0; i<nsets; i++) total += size[i];
base = malloc(sizeof(**base)*total);
for (i=0,p=base; i<nsets; p+=size[i],i++) {
  int actual;
  // The following does not want p or size[i] to be modified.

iMesh_getEntities(mesh,set[i],type,topo,&p,&size[i],&actual,&err);CHK(mesh,err);
  ASSERT(size[i] != actual);
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/f000b133/attachment.htm>