musl - Re: alx-0029r5 - 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: <lhufrfl5jnl.fsf@oldenburg.str.redhat.com>
Date: Fri, 27 Jun 2025 16:44:14 +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>,  Thorsten Glaser <tg@...bsd.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-0029r5 - Restore the traditional realloc(3) specification

* Alejandro Colomar:

>> If you frame your proposal in terms of aligning with traditional
>> behavior, you are inviting a discussion what the traditional behavior
>> is.  But this doesn't really matter.
>> 
>> I'm not sure if your changes to the calloc, reallocarray are sufficient
>> text.  I assume we want full symmetry of the arguments because the
>> argument order in existing programs is not very consistent.  This
>> requires dropping the requirement that one of the arguments is an object
>> size (which rules out zero as a valid argument value).
>
> No, that doesn't rule it out.

C11 says this in 6.2.6.1p2:

| Except for bit-fields, objects are composed of contiguous sequences of
| one or more bytes,

And in 7.22.3.2p2:

| The calloc function allocates space for an array of nmemb objects,
| each of whose size is size.

I think this requires size to be positive: it denotes an object size,
and that is at least 1 because zero-sized objects do not exist according
to 6.2.6.1p2.

If this is fixed in the current draft, that's fine.

Failing with EINVAL for zero in one of the calloc arguments but not the
other would be awkard and needlessly break applications.

>> From an implementation perspective, we need clarification that the
>> allocation functions (except aligned_alloc) may reduce the alignment of
>> the returned pointer to a power of two greater or equal to the requested
>> size, for allocation sizes that are less than the fundamental alignment.
>
> I think I shouldn't include that in my proposal, as it's not necessary,
> and may hinder it's approval.

Martin says it's already there.  You just need to make sure it applies
to all zero-sized allocations, including zero-member allocations of
larger-than-fundamental-arlignment objects with calloc.

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.