Hi Vincent, On Fri, Jun 20, 2025 at 04:36:31PM +0200, Vincent Lefevre wrote: > > So, the input pointer must not be freed. > > Yes, this is what I mentioned in interpretation 1 above (so with > memory leaks in practice, as applications call realloc(non_null,0) > to free memory, while memory will never be freed). > > But I believe that this was not the intent of the C Committee. > If it were, the text would have been different, IMHO. > > This is too late for a defect report anyway, as the current standard > is C23 and realloc(non_null,0) is now UB. But if one wants to avoid > the UB in a future standard, the above remarks need to be considered.
There's a way forward that would prevent the leaks: force the musl behavior: free the object, and return a non-null pointer, like malloc(0). You'd still leak 0 bytes + metadata in a few rare cases, but that's not a big deal. > > I'd say glibc is non-conforming, even if this could possibly have been > > unintended by the C Committee. > > Well, strictly speaking, with the UB, it is conforming (at least with > a non-null pointer). I'm not sure that speaking of conformity against > old standards makes sense if there is a suspicion of defect (and in > particular, if this has been resolved by a change in the current > standard, like here). I think it is important in this case, because if glibc decided to conform to older standards --and it very well could, just as gnulib did--, the UB could be reverted, and users could use realloc(p,0) in the future safely. Now, the ball is in glibc. (Or the standard might unilaterally impose that glibc be fixed, but it would be nicer if glibc would do so voluntarily.) Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
