<div class="gmail_quote">On Fri, Jun 10, 2011 at 22:03, James Porter <span dir="ltr"><<a href="mailto:jvporter@wisc.edu">jvporter@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2hn">It's close, but not quite equivalent. What I'm suggesting is that we<br>
also remove the "alloc=0" means "allocate for me" behavior entirely. The<br>
current patch will allocate a new array when alloc=0, array=non-NULL,<br>
and count>0, but I think it should error out, since:<br>
<br>
1) it simplifies the semantics of the arguments (alloc no longer has a<br>
special value to invoke "allocate for me" behavior)<br>
2) it guarantees that no matter how you specify "allocate for me", that<br>
you have a usable array on return (i.e. you can loop over it and<br>
free() it) because there's only one way to specify that.<br>
<br>
Essentially, if array=NULL, iMesh should be able to totally ignore the<br>
alloc parameter. Granted, like your patch, this requires callers to<br>
change how they initialize their arrays, but I don't think there's a way<br>
around that.</div></blockquote></div><br><div>Okay, I also prefer these stricter semantics, but it's a much bigger API change so it can't be done as casually.</div><div><br></div><div>Here is the proposed logic table:</div>
<div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace">case array alloc actual Allocation Result</font></div><div><font class="Apple-style-span" face="'courier new', monospace">--------------------------------------------------------------</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">A NULL 0 0 no success</font></div><div><font class="Apple-style-span" face="'courier new', monospace">B NULL 0 1+ yes success</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">C NULL 1+ 0 no success</font></div><div><font class="Apple-style-span" face="'courier new', monospace">D NULL 1+ 1+ no ? [1]</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">E valid 0 0 no [2] success</font></div><div><font class="Apple-style-span" face="'courier new', monospace">F valid 0 1+ no failure [3]</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">G valid 1+ 0 no success</font></div><div><font class="Apple-style-span" face="'courier new', monospace">H valid 1+ 1+ no success </font></div>
<div><br></div><div>[1] If you don't allocate, then either SEGV or iBase_BAD_ARRAY_SIZE. Note that you can't actually distinguish a NULL pointer from an invalid pointer (via malloc(0) or otherwise). An error here is just being polite, but the check would be optional for a conforming implementation. Are you suggesting to allocate and succeeed here? That would be more lenient. I don't have a strong rationale either way.</div>
<div><br></div><div>[2] This is the case my patch was concerned with.</div><div><br></div><div>[3] This is your suggestion, which I endorse.</div></div><div><br></div>