Hi Maciej, On Fri, Jun 20, 2025 at 11:58:15PM +0100, Maciej W. Rozycki wrote: > Hi Alejandro, > > > After the useful discussion with Eric and Paul, I've rewritten a draft > > of a proposal I had for realloc(3) for C2y. Here it is (see below). > > I've been following all the previous discussion (despite not having been > explicitly cc'd) and I'm yet going to read through and chew over your > proposal, but not before next week as it's quite late into this one here > already. A thought has struck me however, at the high level. > > Given all the (understandable) fuss and the lack of symmetry (at least in > some implementation variants) between `malloc(0)' and `realloc(p, 0)', and > last but not least conflicting desires, both of which having their pros > and cons,
I honestly still don't see the point in the camp returning NULL. The only reason it hasn't died, I think, is because of fear of breaking existing code, but I don't see anyone asking for that behavior. > how about we actually fulfil the desires of both camps and come > up with a set of entirely new APIs, say (1) `mallocn'/`reallocn' and (2) > `mallocz'/`reallocz', that for zero-sized allocation requests consistently > respectively: > > (1) return NULL, in the case of `reallocn' having freed any previous > allocation, > > (2) return a pointer to a valid allocation, forbidden to access and the > size of which might be zero, in the case of `reallocz' having freed or > possibly shrunk any previous allocation? I don't think (1) is useful. But if anyone thinks so for their code, I suggest they write an obvious inline wrapper for themselves. But such a wrapper should not be provided in the standard library, as it is error-prone. > Implementations could then provide either semantics with their legacy > `malloc'/`realloc' APIs, possibly following your proposal, mostly for > software that does not ever care about zero-sized allocations, which I > think is quite substantial a subset. Code using realloc(3) would continue having hidden bugs. Part of my goal is being able to use realloc(3) in the future without all these issues, but another goal is fixing many existing bugs that no-one even realized their code has. I'm pretty sure you lift a rock and find three bugs in a call to realloc(3). > It seems to me that the overhead for such separate APIs wouldn't be that > high, and where suitable they could even be exported from system headers > as macros or static always inline functions wrapping around the one core > implementation of each, so as to let the compiler optimise away the > uninterested case with many calls to these APIs where the compiler can > statically prove size to be zero or nonzero. > > Thank you for your perseverance with this matter anyway, and have a good > weekend! Thanks! Have a lovely weekend! Alex > > Maciej > -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
