On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote: > * Alejandro Colomar: > > > Here's a new revision of the proposal. I've removed ENOMEM, since it's > > not strictly necessary; it's only necessary that those systems that > > already set it continue setting it (and my proposal for POSIX will > > certainly include ENOMEM). > > As far as I can see, this changes specification across all allocation > functions and requires them to be able to produce zero-sized objects. > Previously, the discussion was about changing realloc only. > > Is this really the right direction, given that > > int a[n]; > > is still undefined, and that C does not support zero-sized objects in > general? > > Wouldn't it be more consistent to move in the other direction, and > require that allocations of zero size fail because C does not support > zero-sized objects? > > (This is why I don't want to make any changes today—we just don't know > what the tightened specification will look like in the published > standard. There are just too many totally reasonable variations.)
This is the change that pretty much nobody wants, except perhaps ideologues out to inflict pain on users and implementors of the language. It makes it harder to write correct code, requiring special-casing of zero all over the place in addition to existing essential difficulties for handlng overflow, and has no tangible advantages. Even the ideological motivation is ill-posed, as the issue of "no such thing as zero-sized objects" was solved *over 3 decades* ago with the language in the standard (it's not a zero-sized object but a pointer you can't dereference that compares non-equal to others). Rich
