Re: Does anybody use Gnulib's eealloc module?

[Paul Eggert]

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.