Am So., 11. Okt. 2020 um 13:56 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > I am not so convinced of whether it makes sense to create a
> > gl_set/gl_map frontend for this hamt implementation.
>
> Wikipedia [1] lists some advantages of HAMTs even without the persistence.
>
> > I
Marc Nieper-Wißkirchen wrote:
> I am not so convinced of whether it makes sense to create a
> gl_set/gl_map frontend for this hamt implementation.
Wikipedia [1] lists some advantages of HAMTs even without the persistence.
> It is optimized
> for the persistence (otherwise, use ordinary hash table
hen we add hamt as a possible implementation for gl_set and gl_map, we
> could document that out-of-memory handling must be done
> - either through xalloc_die(),
> - or by defining xmalloc and xrealloc [this is what Emacs does],
> unlike for the other implementations.
I am not so convin
or
> calling xalloc_die is the only reasonable action.
OK. When we add hamt as a possible implementation for gl_set and gl_map, we
could document that out-of-memory handling must be done
- either through xalloc_die(),
- or by defining xmalloc and xrealloc [this is what Emacs does],
unlike for the other implementations.
Bruno
[1] https://gmplib.org/manual/Custom-Allocation
The out-of-memory handling of gnulib's *printf replacement is broken: it
sometimes sets errno to EINVAL instead of ENOMEM. This fixes it.
2007-11-03 Bruno Haible <[EMAIL PROTECTED]>
Fix out-of-memory handling of vasnprintf.
* lib/printf-parse.c: Include .
(P
