[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <drz3i34mg2ar2v6e4lbhn5zhnvabtqnx5f2bd2ecckxuwrp2ez@ruj24xzftkdq>
Date: Fri, 27 Jun 2025 19:38:44 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.org>
Cc: Florian Weimer <fweimer@...hat.com>, 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>, 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: Re: alx-0029r5 - Restore the traditional realloc(3)
specification
Hi Rich,
On Fri, Jun 27, 2025 at 01:22:17PM -0400, Rich Felker wrote:
> On Fri, Jun 27, 2025 at 06:17:14PM +0200, Florian Weimer wrote:
> > I think the wording still allows calloc (42, 0) to fail with EINVAL (or
> > some other error code) because 0 is not a valid object size.
>
> Since this is also a matter of confusion, I'd like to see it improved.
> In addition to zero being unclear to some readers,
I've slightly tweaked the wording in alx-0029r6. Please check. I've
asked Joseph to review that too.
The rules that prevent 0-sized objects don't trigger, because we never
attempt to create a 0-sized object. It works *as-if* the size was
non-zero, except that the user is not allowed to access the object.
> it's not clear to
> some users (and even implementors) that it must fail if the
> multiplication overflows.
This is off-topic for my proposal.
However, if that would be unclear, I'm willing to improve the wording in
a separate paper. However, I don't find the confusion. The current
wording for calloc(3), as of n3550, is:
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3550.pdf#subsubsection.0.7.25.4.3>
7.25.4.3p3 (Returns):
The calloc function returns
either a pointer to the allocated space
or a null pointer
if the space cannot be allocated
or if the product nmemb * size would wraparound size_t.
So, if n*size would wrap around, it must return a null pointer. How is
it unclear?
Have a lovely day!
Alex
> This is only implied by the impossibility of
> meeting the requirements for the success condition if the
> multiplication would overflow.
>
> The simple unambiguous way to define calloc would be as-if it performs
> malloc followed by memset of size*nmemb bytes, with a requirement to
> fail if the mathematical value of size*nmemb is not representable in
> type size_t (and would thereby be subject to modular reduction).
>
> A non-normative note should say that the intent is that it can be used
> to allocate an array of nmemb objects each of size size, but that
> calloc(size,nmemb) and calloc(nmemb,size) are equivalent and to not
> imply any obligation to access the object as such an array or that
> either value be nonzero.
>
> Rich
--
<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.
