musl - Re: alx-0029r3 - Restore the traditional realloc(3) specification

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lhu1pr9se1i.fsf@oldenburg.str.redhat.com>
Date: Tue, 24 Jun 2025 11:07:53 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Alejandro Colomar <alx@...nel.org>
Cc: 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>,  Eric Blake <eblake@...hat.com>,
  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

* 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?

(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.)

Thanks,
Florian

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.