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/>
signature.asc
Description: PGP signature
