[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250627193712.GS1827@brightrain.aerifal.cx>
Date: Fri, 27 Jun 2025 15:37:12 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.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
On Fri, Jun 27, 2025 at 07:38:44PM +0200, Alejandro Colomar wrote:
> 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.
Yes, that's not what I'm talking about. That's all fine.
> > 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.
I actually largely agree, but at the same time, folks are wrongly
raising this matter as if it were on-topic for your proposal, because
the poor wording of the way calloc is specified seems to generate
confusion that semantics about zero-sized objects are involved when
they're not.
I don't necessarily think fixing this needs to or should be part of
your 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?
OK, I wasn't aware that it was finally clearly spelled out for the
folks who keep finding it surprising. But I was not so much proposing
adding a clarification as just making sure it would still be addressed
if calloc were just specified with malloc+memset(size*nmemb) without
talking about array-like usage.
Sorry if this has been a distraction. I know we have way too many of
those already...
Rich
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.
