<div class="gmail_quote">On Fri, Jun 10, 2011 at 20:16, 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;">
A null pointer can *always* be freed. It's just a no-op.</blockquote></div><br><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>