[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250619153209.GG1827@brightrain.aerifal.cx>
Date: Thu, 19 Jun 2025 11:32:09 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: linux-man@...r.kernel.org, musl@...ts.openwall.com,
libc-alpha@...rceware.org, Paul Eggert <eggert@...ucla.edu>,
Bruno Haible <bruno@...sp.org>, bug-gnulib@....org
Subject: Re: [v2] malloc.3: Clarify realloc(3) standards conformance
On Thu, Jun 19, 2025 at 03:57:47PM +0200, Alejandro Colomar wrote:
> Hi,
>
> Here's a revision of this change, addressing some concerns. I'm only
> showing the formatted changes, since the patch itself is unimportant.
>
>
> Have a lovely day!
> Alex
>
> ---
> $ MANWIDTH=72 diffman-git HEAD
> --- HEAD^:man/man3/malloc.3
> +++ HEAD:man/man3/malloc.3
> @@ -126,15 +126,32 @@
> │ realloc() │ │ │
> └────────────────────────────────────┴───────────────┴─────────┘
>
> +VERSIONS
> + The behavior of realloc(p, 0) in glibc doesn’t conform to any of
> + C99, C11, POSIX.1‐2001, POSIX.1‐2008, POSIX.1‐2017, or
> + POSIX.1‐2024. The C17 specification was changed to make it con‐
> + forming, but that specification was broken —it is impossible to
> + write code that works portably—, and C23 changed it again to
> + make this undefined behavior, acknowledging that the C17 speci‐
> + fication was broad enough that undefined behavior wasn’t worse
> + than that.
This is still full of your polemics. The word "broken" generally
belongs in personal blog posts, not a manual that's supposed to be
documenting the facts of an interface. In fact it is very possible to
write code which works portably: by refraining from passing 0.
Regardless of what action is taken here on the standards or
documentation, that's already been necessary for a long time, and will
continue to be necessary for a long time, because of the existence of
implementations on which passing 0 has inconsistent results.
I would suggest something more like:
The behavior of realloc(p, 0) in glibc doesn’t conform to any of
C99, C11, POSIX.1‐2001, POSIX.1‐2008, POSIX.1‐2017, or
POSIX.1‐2024. C11 was amended in 2017 to allow the glibc
behavior [insert description of exactly how that was done, I
forget] and C23 followed up by making the behavior explicitly
undefined.
In particular, this text is purely matters of fact, no statement of
your or my preferred future outcome or disagreement with what
happened.
I would also move it to CONFORMANCE rather than VERSIONS since
VERSIONS is normally about differences between versions of the
implementation being described, not conformance requirement
differences between versions of the standard.
> +BUGS
> + Programmers would naturally expect that realloc(p, size) is con‐
> + sistent with free(p) and malloc(size). This is not explicitly
> + required by POSIX.1‐2024 or C11, but all conforming implementa‐
> + tions are consistent with that.
This has not historically been a conformance requirement and it is not
one now. Because the behavior is undefined, arbitrarily-inconsistent
behavior is conforming.
It's possible to read this as not stating a conformance requirement,
just a matter of fact that all implementations which conform(ed to
past versions of the standard) happened to also be consistent here.
But in that case I would very much prefer if you make it clear by just
saying that they're consistent on [some explicit list or description
of the class of implementations you've reviewed to have this
property].
> + The glibc implementation of realloc() is not consistent with
> + that, and as a consequence, it is dangerous to call
> + realloc(p, 0) in glibc.
It's not dangerous if you know what it's doing. Rather it's
non-portable. It does something predictable that you can use safely,
but the way you use it safely is different from other, more consistent
implementations in a way that can be a footgun.
> + A trivial workaround for glibc is calling it as
> + realloc(p, size?size:1).
It should probably be noted that use of such a workaround sacrifices
the ability to diagnose logic errors (via sanitizers, valgrind, etc.)
where 1 byte is written to allocated memory that was not intended to
have any accessible bytes of storage.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
