On Wed, Jun 25, 2025 at 01:03:13PM -0500, Eric Blake wrote: > On Wed, Jun 25, 2025 at 07:35:58PM +0200, Alejandro Colomar wrote: > > Hi Eric, > > > > 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. > > Quoting from n3299 (I'm not sure if that's the best draft of C23, or > if I should attempt to get my hands on a more-precise pdf): > > "The realloc function deallocates the old object pointed to by ptr and > returns a pointer to a new object that has the size specified by > size. The contents of the new object shall be the same as that of the > old object prior to deallocation, up to the lesser of the new and old > sizes. Any bytes in the new object beyond the size of the old object > have unspecified values." > > "The realloc function returns a pointer to the new object (which can > have the same value as a pointer to the old object),..." > > Return values are not "new pointers", but "new objects". Your > proposal is not changing the fact that all successful allocations are > "new objects", and the standard is already clear that new objects can > live in the same pointer. But I still feel that it is worth the > footnote to remind casual readers that even though reusing the pointer > is permissible, it is not mandatory, and as a result, code that > blindly assumes that shrinking an object will reuse the old pointer is > broken. (That change is independent of whether we fix realloc(p,0), > but since we're in the area, we might as well make the standard easier > to use).
Okay, sounds reasonable for just a few words; I'll add them. Cheers, Alex > > By the way, even though the most common reason that the old and new > pointer are the same is in order to avoid having to copy/move data > from the old object to the new, there is another interesting case that > the standard permits: an implementation that uses mmap() can have > cases where the old pointer is different from the new pointer but > where none of the object data had to be copied or moved, and that's > because implementations can take advantage of MMU mapping metadata to > direct the new pointer into resolving to the same underlying storage > as the old pointer used to see. > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. > Virtualization: qemu.org | libguestfs.org > -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
