[Bug-gnulib] Re: remove dependency of xalloc on gettext, error, etc.

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> Like a xmalloc.c that does puts(strerror (ENOMEM)) instead of
>> requiring error + gettext, both of which are huge and complex.
>
> How about this patch instead?  It removes the dependency of xalloc on
> those other modules in a different way: by having the app specify
> xalloc_die, and by supplying a different module xalloc-die for apps
> that want the current behavior.

I like it, and have started to use it in GSS.

Your patch has another nice property: if the xalloc-die implementation
want to support a "xalloc_fail_func" style callback to the
application, it can do so using the same namespace as the rest of the
library that use xalloc.  So GSS can name the callback
gss_alloc_fail_function.

(I'm still not convinced it is a good idea to use xalloc at all in a
library, though, but your patch take care of my problems with the
actual implementations... now my remaining objections are only
conceptual.  I'll let GSS be an experiment for how well this work.)

Updated gnulib/doc/xalloc.texi below, it is not written for gnulib,
but for GSS.  Eventually it would have to be cleaned up for gnulib
audience...  but it is a starting point.

> +  error (exit_failure, 0, "%s", _("memory exhausted"));

I'm not that good with gettext, so, btw, is this string (and others in
gnulib files) supposed to be translated for each package?  Perhaps
there could be a "gnulib" gettext domain, to reduce translation
duplication.  (Or strerror (ENOMEM) could be used, in this case,
unless that's a bad idea somehow.)

Thanks,
Simon

@node Out of Memory handling
@section Out of Memory handling

@cindex Out of Memory handling
@cindex Memory allocation failure
The GSS API does not have a standard error code for the out of memory
error condition.  Instead of adding a non-standard error code, this
library has chosen to adopt a different strategy.  The rationale for
the strategy chosen is that out of memory handling happens in rare
situations, but performing the out of memory error handling after many
API function invocations make source code harder to read.  That may
make it harder to spot more serious problems.  The strategy chosen
improve code readability and robustness.

@cindex Aborting execution
For most applications, aborting the application with an error message
when the out of memory situation occur is the best that can be wished
for.  This is how the library behaves by default.

@vindex gss_alloc_fail_function
However, we realize that some applications may not want to have the
GSS library abort execution in any situation, or that the error
message should go somewhere else than to @code{stderr}.

To meet this need, the GSS library support a callback function to let
the application regain control, and perform its own cleanups, when an
out of memory situation has occurred.  The application can define a
function and set the library variable @code{gss_alloc_fail_function}
to that function.  This could be implemented as follows.

@example
#include <gss/ext.h>
...
void my_gss_alloc_failer (void)
@{
      syslog (LOG_CRIT, "GSS library out of memory");
      exit (1);
@}
...
int
main (int argc, char *argv[])
@{
  ...
  gss_alloc_fail_function = my_gss_alloc_failer;
...
@end example

The GSS library will invoke @code{gss_alloc_fail_function} if an out
of memory error occurs.  Note that after this all previously allocated
GSS library variables are in an undefined state, so you must not use
any previously allocated GSS variables again.  You could discard all
previous GSS variable and start from scratch, though.  The hook is
only intended to allow the application to log the situation in a
special way.  Of course, care must be taken to not allocate more
memory, as that will likely also fail.

As can be seen, the callback is a global variable, and is thus not
thread safe.  It is assumed that if @code{malloc} fail in one thread,
it likely do the same for all threads within the application.