On Wed, Jun 25, 2025 at 06:07:06PM +0000, Wilco Dijkstra wrote: > Hi Alejandro, > > > > > > +XXX) > > > > > +While atypical, > > > > > +<b>realloc</b> may fail > > > > > +for a call that shrinks the block of memory. > > > > > > > > Is it worth wording this as "may fail or return a different pointer > > > > for a call that shrinks the block of memory"? > > > Oh, the text is still there; I didn't see it. :) > > > The realloc function returns a pointer to the new object > > (which can have the same value as a pointer to the old object), > > or a null pointer if the new object has not been allocated > > In principle a realloc that shrinks a non-NULL block does never need to fail. > If it can't shrink the current block (either because internal design means it > can't make it any smaller or because it doesn't have memory for a new > smaller block) then it should preferably return the original pointer instead > of returning NULL and taking the failure path. > > So I'm wondering whether we should more clearly specify this - whenever > it's possible to not fail, don't return NULL?
Rich already made the strong argument that for an implementation that encodes which arena a pointer was allocated from, shrinking in place only works so long as the unused tail of the allocation does not exceed a certain bound; and Alejandro removed the quote from Doug McIlroy from an earlier version of the draft precisely because we do NOT want the standard to mandate the inability to fail on shrinking an object, as that will harm quality-of-implementation. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
