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

[Jason Kraftcheck]

On 06/10/2011 01:37 PM, James Porter wrote:
> On Fri, 2011-06-10 at 20:30 +0200, Jed Brown wrote:
>> 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.
> 
> I honestly can't think of any case where an undefined array pointer is
> "safer" than a null array pointer. If you're iterating over a zero-sized
> array, you'll just never enter the body of the loop; no extra handling
> required. If you're doing something that would barf on a null pointer,
> an undefined pointer is going to be even worse, since you'll almost
> certainly be accessing an invalid memory location. A stale pointer value
> will also be bad in nearly every similar situation, since you'll
> probably end up writing to the wrong place in memory.
> 
> Could you provide an example of a case where an undefined pointer would
> be ok, but a null pointer would cause problems?
> 

What happens in the code below if a) 'set' doesn't contain any vertices and
b) on the system it is run on malloc(0) returns a non-null pointer that must
be free'd?


int size;
iMesh_getNumOfType( instance, set, iBase_VERTEX, &size, &err );
iBase_EntityHandle* verts =
      (iBase_EntityHandle*)malloc(size*sizeof(iBase_EntityHandle);
int* junk = 0;
iMesh_getEntities( instance, set, iBase_VERTEX, iMesh_POINT, &verts,
                   &size, &junk, &err );
for (i = 0; i < size; ++i)
  do_my_vertex_op( instance, verts[i] );
free(verts);