Marc Nieper-Wißkirchen wrote: > > 2) We have a dilemma regarding use of malloc vs. xmalloc. While modules > > meant for use in programs can readily use xmalloc, modules meant for > > use > > (also) in libraries cannot use xmalloc, since a library is not supposed > > to terminate the program, even when memory is tight. > > GMP more or less has this behavior.
Indeed, GMP's out-of-memory options [1] are poor in this respect: "There’s currently no defined way for the allocation functions to recover from an error such as out of memory, they must terminate program execution. A longjmp or throwing a C++ exception will have undefined results." Likewise for libffcall, alas. > > The solution we found for this dilemma is that the *-set and *-map > > modules > > use just malloc, and we have thin wrapper modules (xset, xmap) that do > > call xalloc_die() in case of out-of-memory. > > > > Unfortunately, the API of many of the functions need to be adjusted to > > cope with the possibility of an ENOMEM failure. That is tedious work, > > and > > the code does not look so pretty afterwards... But I see no other way > > to > > make it fit for use in libraries. > > The bigger problem is that it mustn't make the code slower for the > 99,99999% of the use cases where there is either enough memory 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