[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <g44ntye4chtcazy2oa6xvmw7bi2j4aipxizq3rnl6y2by44kxc@fxyx34iugjx4>
Date: Tue, 24 Jun 2025 16:35:54 -0500
From: Eric Blake <eblake@...hat.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Alejandro Colomar <alx@...nel.org>, libc-alpha@...rceware.org,
bug-gnulib@....org, musl@...ts.openwall.com,
наб <nabijaczleweli@...ijaczleweli.xyz>, Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
Paul Eggert <eggert@...ucla.edu>, Robert Seacord <rcseacord@...il.com>,
Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>, Rich Felker <dalias@...c.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, Joseph Myers <josmyers@...hat.com>,
Laurent Bercot <ska-dietlibc@...rnet.org>, Andreas Schwab <schwab@...e.de>,
Vincent Lefevre <vincent@...c17.net>, Mark Harris <mark.hsj@...il.com>,
Collin Funk <collin.funk1@...il.com>, Wilco Dijkstra <Wilco.Dijkstra@....com>,
DJ Delorie <dj@...hat.com>, Cristian Rodríguez <cristian@...riguez.im>,
Siddhesh Poyarekar <siddhesh@...plt.org>, Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
"Maciej W. Rozycki" <macro@...hat.com>, Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>, eskil@...ession.se,
Daniel Krügler <daniel.kruegler@...glemail.com>, Kees Cook <keescook@...omium.org>,
Valdis Klētnieks <valdis.kletnieks@...edu>
Subject: Re: alx-0029r3 - Restore the traditional realloc(3) specification
On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote:
> * Alejandro Colomar:
>
> > Here's a new revision of the proposal. I've removed ENOMEM, since it's
> > not strictly necessary; it's only necessary that those systems that
> > already set it continue setting it (and my proposal for POSIX will
> > certainly include ENOMEM).
>
> As far as I can see, this changes specification across all allocation
> functions and requires them to be able to produce zero-sized objects.
> Previously, the discussion was about changing realloc only.
>
> Is this really the right direction, given that
>
> int a[n];
>
> is still undefined, and that C does not support zero-sized objects in
> general?
>
> Wouldn't it be more consistent to move in the other direction, and
> require that allocations of zero size fail because C does not support
> zero-sized objects?
No. As long as there are two camps of behaviors (traditional
vs. SysV) [well, three camps if you count glibc's behavior that
mixes-and-matches traditional for malloc(0) and realloc(0,0) but SysV
for realloc(p,0) because of unfortunate C89 wording]), you need to
consider the impact of code written for one camp being run on a
platform that implements the other camp. Code written for traditional
but run on a SysV platform can double-free, which can lead to RCE;
while code written for SysV but run on traditional merely leaks the
non-NULL pointer returned for a 0-byte allocation. Of those two
failure scenarios, an eye towards safer programming should have no
hesitation in recognizing that getting rid of SysV behavior is the
only sensible approach that won't introduce double-free and RCEs in
code. (Code written portably avoids realloc(p,0) altogether, often by
the n?n:1 trick - and that code will still work regardless of what the
standard ends up saying for size 0)
>
> (This is why I don't want to make any changes today—we just don't know
> what the tightened specification will look like in the published
> standard. There are just too many totally reasonable variations.)
I can understand not wanting to make the changes if you aren't sure if
the C committee will go with wording that differs from the changes you
might make; but that sounds like a different stance ("wait and see
what the committee says before changing things to match") than never
making the change at all ("over my dead body, so any change the
committee makes will be ignored"). Expressing a willingness to make a
future change if the C committee's change is good will help in getting
the consensus for the C committee to make a good change.
We also need a bug filed against POSIX to either match or extend what
the C committee decides. For example, even if the C committee ends up
sticking with C23's "size 0 is undefined behavior", POSIX may still
want to go with a tighter definition that "size 0 is well-defined and
always allocates a distinct pointer on success" if it will not
alienate too many existing POSIX implementations. And glibc is one of
those interesting cases where there is no one single vendor trying to
keep glibc and the Linux kernel in sync with POSIX, but where POSIX
generally tries hard to not alienate glibc behavior.
[Counter-examples being things like Linux behavior on
mkdir("dangling_symlink/") are an entirely different discussion...]
--
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.
