On 03/25/2011 06:53 AM, Eric Blake wrote: > +/* Change the size of an allocated block of memory P to N bytes, with > + error checking. This version explicitly rejects non-NULL P > + combined with N of 0, since the GNU realloc semantics of freeing P > + and returning NULL interfere with the promise of x*alloc methods > + never returning NULL. */
This doesn't sound right. xrealloc shouldn't reject a set of arguments that realloc accepts. Also, it doesn't match the comments and other code in the module. The x*alloc methods by and large don't promise that they return a non-NULL pointer. What they promise, is that they check for out-of-memory conditions, so that the caller doesn't have to. For example, xmalloc (0) always succeeds, no matter what; it never invokes xalloc_die (). If the underlying malloc (0) returns NULL, xmalloc (0) returns NULL. The caller can't dereference the NULL, but that's OK, as the caller couldn't dereference any non-NULL returned value either. The situation for xrealloc (p, 0) should be similar to that of xmalloc (0). Now, perhaps we should think about changing the semantics, so that the x*alloc methods always return non-NULL. But does any application require the changed semantics? If not, I'd be leery about changing them.
