On Wed, Jun 25, 2025 at 07:47:55PM +0200, Alejandro Colomar wrote: > Hi Eric, > > On Wed, Jun 25, 2025 at 07:36:01PM +0200, Alejandro Colomar wrote: > > On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote: > > > > > @@ New footnote XXX > > > > > +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"? > > > > > > Yeah, we can add that. > > > > I've changed my mind; the current wording of ISO C makes it that all > > realloc(3) successful return values are new pointers, and it doesn't > > seem to mention that the old pointer could be kept (I remember having > > seen such text in older standards, I think; or maybe in POSIX), so let's > > keep in that sense, and assume that realloc(3) always moves the memory, > > even if sometimes it doesn't, as that is not observable by a conforming > > program. > > 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 > > I think I'll just remove that parenthetical, since it serves little > purpose.
On the contrary, I think the parenthetical has a great purpose - it is a hint to implementors that preserving the pointer values between the old and new object is a desirable (but not mandatory) characteristic. Deleting the parenthetical might cause people to misinterpret the standard by mixing up "new object" with "new pointer", at which point they might try to "fix" realloc(p,s) to never return p but always copy data. When doing valgrind or other similar malloc-checking analysis of a program, I'd actually WANT that behavior for realloc, to make sure my code is always safely dealing with any potential of a moved pointer; but in the common case, I do NOT want the speed penalty of an implementation that always has to copy memory rather than reusing pointers just because the standard omitted the parenthetical hinting that such behavior is permissible. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
