Hi Florian, On Fri, Jun 27, 2025 at 10:52:02AM +0200, Florian Weimer wrote: > * Alejandro Colomar: > > > It would be good to have explicit replies by glibc maintainers about it, > > so that the C Committee understands better what the maintainers think > > about it. I've got word from some committee members that if I can > > convince the maintainers, they'll vote for standardizing it. So, it > > would be great it people could emit 'Acked-by:' tags, or otherwise > > explain their position. > > This is not how ISO standardization works.
I'm member of the C Committee; I know how it works. > In the end, it comes down to > how the national bodies vote. It comes down to this: - I present a proposal (which I've already submitted; soon it will appear in the document log). <https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log> - The proposal is voted by the committee members in the next meeting (that is, in two months, most likely). If it's approved, it is put into the working draft. - Close to release of C2y, National Bodies may issue comments opposing the draft. This is unlikely to change things meaningfully, if the previous step had strong consensus. > I think the proposal is not clear about its intent. It looks to me you > are trying to accomplish at least the following things: > > * all allocation functions can be used to allocate zero-sized objects > * calloc, reallocarray can be used to allocate arbitrary large arrays > of zero-sized objects > * calloc, reallocarray can be used to allocate zero-length arrays > of arbitrarily-sized objects > * realloc, reallocarray can no longer be used to deallocate storage Yes, that's correct. That's how they behave in musl and the BSDs (and for calloc(3), in glibc too). BTW, reallocarray(3) is not in ISO C (yet). > 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. calloc(3) is implemented in the BSDs, musl, and glibc, that way, and it is conforming to ISO C (I think nobody disputes that). The relevant text in the standard is this: 7.25.4.1 Memory management functions :: General @@ p1 ... If the size of the space requested is zero, -the behavior is implementation-defined: -either -a null pointer is returned to indicate the error, -or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. That paragraph talks about the total size, not the size of each object. If you read calloc(3), "the space" refers to the entire space, while each object within the array is referred to as "each object". So, this paragraph, which says what happens when the total size is zero, doesn't care if it's due to 'n' being 0 or 'size' being 0. > 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. > (Some existing implementations already do this today, in violation of > the standard.) Feel free to propose such a change. Have a llovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
