Paul Eggert wrote:
> (We have too
> many memory allocation modules and a cleanup is needed, but that's a
> different topic....)
It's easy to get this feeling. But the fix, IMO, is to give an overview
of the modules in the documentation, and how they differ.
> > How could we call this module? 'realloc-ee' sounds too synthetic.
>
> How about 'alloc-0-nonnull'?
>
> Whatever the module's name is, it should affect malloc too, as there's
> little point to adjusting realloc without also adjusting malloc.
A dependency from the new module to 'malloc-gnu' should fit the bill, no?
Then I would opt for the name 'realloc-0safe', with such a dependency.
> Similarly for alignalloc, aligned_alloc, aligned-malloc, calloc,
> posix_memalign, reallocarray, safe-alloc, and maybe others.
For calloc we already have 'calloc-gnu', that does it.
For the others, I would say that '*-0safe' variants are not needed, because
the allocation is special and therefore the programmer can be assumed to be
careful there (cf. option (c) in [1]).
> I don't think we need to worry about alloca and malloca as they've never
> had this problem.
I agree.
> The lib/allocator.h API may need to change even if that's only to
> commentary.
Yes. In fact, this part is easy to handle, since, according to
codesearch.debian.net,
- the only allocator ever used is the stdlib_allocator,
- the only function that makes use of it is careadlinkat()
(either from gnulib or from emacs/src/w32.c).
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-10/msg00190.html
