[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <epzoebbkaqmo627622nacfw4gvvomayc2ev7ufebcrpo2izae3@tfafskjvtjgi>
Date: Thu, 19 Jun 2025 13:50:01 -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 01:42:38PM -0500, Eric Blake wrote:
> > +
> > + 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.
That is, unless a future revision of POSIX adds intentional <CX>
shading to state that on POSIX platforms, realloc(non_null, 0) has
well-defined behavior, and therefore making it usable on POSIX systems
even if not appropriate for generic C systems.
--
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.
