On 2024-10-27 11:53, Bruno Haible wrote:
I see. So, you're going for a "transversal" module, like 'sigpipe' or 'nonblocking'.
After trying to write that I decided it wasn't worth the trouble. Instead, I folded the new stuff into realloc-posix, as you can see from recent emails I just sent to bug-gnulib. I tried to follow a similar model as malloc-gnu for this, but of course could have made mistakes. In particular I didn't test C++.
The module argz had an unusual code path that I think could have invoked realloc (p, 0), which I fixed by having argz depend on the new realloc-posix.
To some extent this means "realloc-posix" is trickily named. Yes, glibc realloc does not conform to POSIX so realloc-posix is within its rights to replace glibc realloc; but realloc-posix goes beyond what POSIX requires, and it'll even replace AIX-sans-_LINUX_SOURCE_COMPAT realloc, which does conform to POSIX. On the other hand we were already stretching the point here since POSIX allows realloc to succeed with sizes greater than PTRDIFF_MAX whereas realloc-posix already prohibited that. Plus, realloc-posix now supplies simple and commonly-assumed semantics for realloc, so there's that.
Maybe we should rename realloc-posix back to realloc? On the other hand there is some virtue with not messing further with names.
The modules amemxfrm, safestriconveh, string-buffer could be simplified slightly by depending on realloc-posix and assuming the new realloc-posix behavior.
I haven't yet messed with eealloc, which should be redundant now. Comments welcome as usual.
