[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rn4grpehjs2z6ntam7dze32gugdfokwani2v7tuuc6camjdzy3@btjl3c4ff5i3>
Date: Thu, 19 Jun 2025 12:54:52 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.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
Hi Rich,
On Wed, Jun 18, 2025 at 10:15:10PM -0400, Rich Felker wrote:
> > $ 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,
Okay, I'll reword, and try to be more objective. A new BUGS section
would be good for it:
$ MANWIDTH=72 diffman-git -U8
grotty:<standard input>:(<standard input>):9: warning: unrecognized X command 'sgr 0' ignored
grotty:<standard input>:(<standard input>):9: warning: unrecognized X command 'sgr 0' ignored
--- HEAD:man/man3/malloc.3
+++ ./man/man3/malloc.3
@@ -129,19 +129,17 @@
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.
+ than that.
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.
@@ -228,16 +226,29 @@
POSIX requires memory allocators to set errno upon failure.
However, the C standard does not require this, and applications
portable to non‐POSIX platforms should not assume this.
Portable programs should not use private memory allocators, as
POSIX and the C standard do not allow replacement of malloc(),
free(), calloc(), and realloc().
+BUGS
+ Programmers would naturally expect that realloc(p, n) is consis‐
+ tent with free(p) and malloc(n). This is not explicitly re‐
+ quired by POSIX.1‐2024, but all conforming implementations are
+ consistent with that.
+
+ The glibc implementation of realloc() is not consistent with
+ that, and as a consequence, it is dangerous to call
+ realloc(p, 0) in glibc.
+
+ A trivial workaround for glibc is calling it as
+ realloc(p, n?:1).
+
EXAMPLES
#include <err.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MALLOCARRAY(n, type) ((type *) my_mallocarray(n, sizeof(type)))
> nor stating as
> undisputed fact aspects of conformance that seem to be under
> disagreement.
You're welcome to ask the committee for a clarification of the wording.
I don't think it's open to interpretation.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
