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
