Upon re-reading the iMesh.h spec, this would be a change of<div><br></div><div><div>If a list argument is unallocated (the list pointer points to a NULL value) or if the incoming value of the allocated size is zero, the list storage will be allocated by the implementation. IN ALL CASES, MEMORY ALLOCATED BY ITAPS INTERFACE IMPLEMENTATIONS IS DONE USING THE C MALLOC FUNCTION, AND CAN BE DE-ALLOCATED USING THE C FREE FUNCTION.</div>
<div><br></div><div>to only allocating memory if the result size is also positive. I think my semantics are much more practical. The only place where it is backward incompatible is when the caller passes in</div><div><br>
</div><div>list = undefined;</div><div>alloc = 0;</div><div>iMesh_callReturningList(...,&list,&alloc,&size,...);</div><div>for (i=0; i<size; i++) use(list[i]);</div><div>free(list);</div><div><br></div><div>
This can be fixed by simply setting list = NULL before the call. Doing so is no burden and if anything, makes the code clearer. In the interest of clarity, I don't think it would be unreasonable to require that BOTH list=NULL and alloc=0 for library-allocated memory. It becomes an iBase_BAD_ARRAY_SIZE if list=non-NULL, alloc=0, and a positive number of items are to be returned.</div>
<div><br></div><div>In any reasonable scenario I can envision, the caller knows statically whether they want the library to allocate memory or not. The caller would need a run-time check to determine whether they computed an expected array length that was positive or equal to zero.</div>
<div><br></div><div>For my use case (filling a preallocated contiguous buffer in segments) the user would need to have an if statement and avoid the call when an empty array is expected. This makes user code ugly and fragile.</div>
<br><div class="gmail_quote">On Fri, Jun 10, 2011 at 14:08, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
It is relatively common to fill a buffer with consecutive queries, some<br>
of which may return zero items. In such scenarios, the user passes in a<br>
valid pointer, but occasionally a length of 0. In such scenarios,<br>
having the library allocate a new buffer of zero length is not<br>
desirable.<br>
<br>
On the other hand, if a user knowingly passes in a length of zero, but<br>
undefined pointer value, they would expect the library to return a<br>
pointer that can safely be passed to free(). A workaround is to nullify<br>
the pointer prior to calling iMesh with expectation of a new array.<br>
---<br>
itaps/imesh/iMesh_MOAB.hpp | 2 +-<br>
1 files changed, 1 insertions(+), 1 deletions(-)<br>
<br>
</blockquote></div><br></div>