[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250619021510.GD1827@brightrain.aerifal.cx>
Date: Wed, 18 Jun 2025 22:15:10 -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: malloc.3: Clarify realloc(3) standards conformance
On Thu, Jun 19, 2025 at 02:42:14AM +0200, Alejandro Colomar wrote:
> Hi!
>
> I've applied a patch to document the conformance of realloc(3) and
> reallocarray(3). See below, both the patch, and the formatted changes.
>
> BTW, Paul, Bruno, does gnulib also wrap reallocarray(3)? If not, it
> should.
>
>
> Have a lovely day!
> Alex
>
> ---
> commit 7279622113349f32428fa14467ba2aa9ef090394
> Author: Alejandro Colomar <alx@...nel.org>
> Date: Thu Jun 19 02:27:48 2025 +0200
>
> man/man3/malloc.3: VERSIONS, STANDARDS: Clarify conformance of realloc{,array}(3)
>
> Signed-off-by: Alejandro Colomar <alx@...nel.org>
>
> diff --git a/man/man3/malloc.3 b/man/man3/malloc.3
> index 9cdfa6b58..bd6cc161f 100644
> --- a/man/man3/malloc.3
> +++ b/man/man3/malloc.3
> @@ -241,6 +241,37 @@ .SH ATTRIBUTES
> .BR realloc ()
> T} Thread safety MT-Safe
> .TE
> +.SH VERSIONS
> +The behavior of
> +.I 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 conforming,
> +but that specification was broken
> +\[em]it is impossible to write code that works portably\[em],
> +and C23 changed it again to make this undefined behavior,
> +acknowledging that the C17 specification was broad enough that
> +undefined behavior wasn't worse than that.
> +The POSIX.1-2024 specification is good,
> +and ideally the ISO C standard should embrace something similar,
> +but glibc does not conform to it.
> +.P
> +musl libc conforms to all versions of ISO C and POSIX.1.
> +.P
> +gnulib provides the
> +.I realloc-posix
> +module,
> +which provides a wrapper
> +.BR realloc ()
> +that conforms to POSIX.1-2024.
> +.P
> +.BR reallocarray ()
> +suffers the same issues in glibc.
> .SH STANDARDS
> .TP
> .BR malloc ()
> @@ -250,10 +281,10 @@ .SH STANDARDS
> .BR calloc ()
> .TQ
> .BR realloc ()
> -C11, POSIX.1-2008.
> +C23, POSIX.1-2024.
> .TP
> .BR reallocarray ()
> -None.
> +POSIX.1-2024.
> .SH HISTORY
> .TP
> .BR malloc ()
>
> $ MANWIDTH=72 diffman-git HEAD
> --- HEAD^:man/man3/malloc.3
> +++ HEAD:man/man3/malloc.3
> @@ -126,15 +126,34 @@
> │ 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. The POSIX.1‐2024 specification is good, and ideally
> + the ISO C standard should embrace something similar, but glibc
> + does not conform to it.
> +
> + musl libc conforms to all versions of ISO C and POSIX.1.
> +
> + gnulib provides the realloc‐posix module, which provides a wrap‐
> + per realloc() that conforms to POSIX.1‐2024.
> +
> + reallocarray() suffers the same issues in glibc.
I don't like this text, at least not the second half. Man pages are
not supposed to be polemic. They should be documenting the interface
and what standards the implementation does or doesn't conform to, not
declaring changes to the standards good or bad, nor stating as
undisputed fact aspects of conformance that seem to be under
disagreement.
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.
