On 16/06/25 08:55, Alejandro Colomar wrote:
> Hi!
>
> For context, the old discussion was in this thread:
> <https://inbox.sourceware.org/libc-alpha/nbyurzcgzgd5rdybbi4no2kw5grrc32k63svf7oq73nfcbus5r@77gry66kpqfr/>
>
> Also for context, here's the excellent research by наб about malloc(0)
> and realloc(p, 0) in historic UNIX systems and their descendents:
> <https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html>
>
> We discussed last year about realloc(p, 0) being problematic currently
> in glibc. Ideally, realloc(p, n) should be consistent with malloc(n)
> in that:
>
> - It is equivalent to free(p) and malloc(n), regardless of the value of
> n, including when it is 0, and regardless of p, including when it is
> NULL.
>
> - Except that of course, if there's enough contiguous space, it doesn't
> free/malloc, and taht if malloc(n) fails, it doesn't free(p).
>
> This congruency existed in every UNIX system and their descendents,
> including the historic BSDs. It wasn't until new systems were written
> artificially by the letter of the standard, without regards to
> self-consistency, when this congruency was broken. I believe glibc was
> the first one to do that, and I don't know/remember if any other systems
> followed glibc.
>
> Paul Eggert and I are convinced that changing the implementation to
> conform to this behavior consistent with malloc(0) would be harmless.
> As such, we modified gnulib's realloc-posix module to conform to that.
> This was done in
>
> d884e6fc4a60 (2024-11-03, 2024-11-04; "realloc-posix: realloc (..., 0)
> now returns nonnull")
>
> After more than half a year of changing the behavior in gnulib, there
> have been no dramatic consequences. As expected, no fallout at all.
>
> Now, can we please make the same change in glibc?
>
> I've CCed musl and Elliott (Bionic), because I don't remember what's the
> behavior in their libraries. Is it already self-consistent in musl and
> Bionic? Or do they need a similar fix?
>
> glibc (and possibly libraries that attempt glibc compatibility) is the
> only libc implementation that is not self consistent, and by which ISO C
> has UB in realloc(p, 0). We expect that when glibc is fixed,
> realloc(p, 0) can be allowed again in ISO C, and can be specified to be
> consistent with malloc(0), thus removing a case of UB.
I have re-read the whole thread and it seems that most maintainers are OK
with this change and agree that current POSIX's realloc spec has some
drawbacks (albeit it still allows current glic behavior).
The only one involved in the previous thread that raised some objection to
this change was Joseph [1], but I will let to say if he still think this
potential change to glibc is ill-advised.
So what I would expect to move this forwards will be to.
1. Reopen https://sourceware.org/bugzilla/show_bug.cgi?id=12547
2. Follow the suggestions laid out by Siddhesh [2]. The Distribution-wide
verification seems already to be in progress, with some good results
from gnulib realloc replacement and some work by you on checking some
other projects (systemd for instance).
3. Prepare the patch to change it, along with the manual documentation,
regression testcase, and the NEW entry.
4. Since we are near to 2.42 release, this change should be done once
2.43 starts to give some time to check potential issue with rolling
distros like Fedora Rawhide.
What I do *not* think it would be worthwhile is adding either a compile
or runtime (through tunables) to reinstate old behaviour; this is really
adds some maintainability burden to what seems to be bad behavior that
eventually will be removed from standards. I am not sure about a
compatibility symbol.
[1]
https://inbox.sourceware.org/libc-alpha/ece1e7ef-ad40-e5cd-9aa4-438854fe4...@redhat.com/
[2]
https://inbox.sourceware.org/libc-alpha/a69a4a81-208e-4d8c-8201-05f657e9f...@gotplt.org/
