[Bug-gnulib] Re: Reorganization

[Simon Josefsson]

Jim Meyering <address@hidden> writes:

> Simon Josefsson <address@hidden> wrote:
>> My main example is the xalloc module, which depend on error,
>> unlocked-io, extensions, exitfail, inline, gettext and other stuff,
>> which brings in a considerable amount of code for something that
>> ideally should be a simple wrapper around malloc and friends.
>>
>> Since I use the code in a library used by server processes, the
>> printed error message will rarely be seen even in the remote cases
>> when an out of memory condition do occur, so I don't consider it that
>> important, but even so I replaced:
>>
>>   error (exit_failure, 0, "%s", _(xalloc_msg_memory_exhausted));
>>
>> with[1]
>>
>>   errno = ENOMEM;
>>   perror (PACKAGE);
>
> If that's the only problem then can you set xalloc_fail_func
> to a function that does the above and then calls abort?

The code calling error would still be present in xmalloc.c, which is
the problem.  Having two versions of xmalloc.c, or parametrization of
the code somehow, would solve it.  I don't really like CPP #ifdef's
(it makes the code unreadable and hard to audit), so perhaps another
idea is to have gnulib-tool create two different versions of the code
depending on some parameter somewhere.  Perhaps using m4.

> But maybe it's something deeper.
> I'm not sure I'd want a server aborting, even if it fails to allocate
> some memory.  The gnulib x* functions were not designed for use in server
> applications.  Maybe you need specialized versions of those functions.

Yes.  Applications using my library are encouraged to set the callback
and destroy the library handle when it happens.

But I've also thought about a version of the xalloc module that
doesn't fail on out of memory errors, which might be useful since the
module contains several new useful memory APIs, like clone etc.  This
could be another parametrization of the module..

(Just for the record, I don't think parametrization of modules should
be implemented lightly.  It will complicate things alot, so a well
thought out plan should be written down before going down that
road..  I don't have a plan, and I'm not even convinced a good plan
can be devised.)