[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nd62th7wphcfw7k2grg2a6y4rbet53d4mljmwhkoelrg43dtpm@rpjskrdvlpw6>
Date: Thu, 19 Jun 2025 13:42:38 -0500
From: Eric Blake <eblake@...hat.com>
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.
See my other (lengthy!) email about how I'm not yet convinced that you
have succesfully proven non-conformance to C99, C11, POSIX 2001, POSIX
2008, or POSIX 2017. However, I agree that from my initial reading,
glibc appears to be non-conforming to POSIX 2024, _except that_ it may
have been an unintentional bug in POSIX 2024, and in today's Austin
Group call, a request was made to open a bug against POSIX if we think
the standard is wrong for having declared glibc non-conforming.
> 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.
In addition to the other feedback you've been given (avoid the word
"broken" - that's a judgement call), I want to reiterate that it is
more important to focus on facts. It's not enough to say "glibc is
non-compliant"; better would be to state "standard XYZ states
realloc(non_null,0) must do ABC but glibc does DEF instead".
Remember, there are users who LIKE the glibc behavior and don't care
whether the standard says otherwise; but there are ALSO users who are
surprised to learn glibc does not follow what the standard says. But
Knowing only the vague assertion that "glibc is non-compliant" does
not help me judge what seems to be the problem. It is more important
that I know that "my code is non-portable if I use this specific
construct", at which point I am in a better position to judge "well I
only run on glibc so who cares", or "oh, to make my code less risky
during porting, I can do something about it", whether by importing
gnulib modules, rewriting my code to avoid realloc(XXX,0), upgrading
to a newer glibc (if glibc ever agrees to change behavior), using an
alternative malloc library, or something else altogether.
> +
> + 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.
> +
> STANDARDS
> malloc()
> free()
> calloc()
> realloc()
> - C11, POSIX.1‐2008.
> + C23, POSIX.1‐2024.
>
> reallocarray()
> - None.
> + POSIX.1‐2024.
>
> HISTORY
> malloc()
> @@ -214,6 +231,22 @@
> POSIX and the C standard do not allow replacement of malloc(),
> free(), calloc(), and realloc().
>
> +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.
You may also want to be more precise on realloc(NULL, 0) (which IS
required to behave like "malloc(0)") and realloc(non_null, 0) (where
things have varied over the years in the standards, even if glibc
behavior has been constant through that time).
> +
> + The glibc implementation of realloc() is not consistent with
> + that, and as a consequence, it is dangerous to call
> + realloc(p, 0) in glibc.
More importantly, with C23 making it undefined behavior, it is
dangerous to call realloc(non_null, 0) in ANY libc, ever. Regardless
of whether glibc documents semantics that comply (or don't comply)
with older standards.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
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.
