[Bug-gnulib] Re: drop unlocked-io dependency in getline module?

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

>> error: assumes the application add a symbol 'program_name'.  This is
>> difficult to do properly if my application is a library with its own
>> namespace.
>
> What should "error" do in such a situation?  Should it not bother to
> use a program name at all?  That could be arranged, I suppose.

Here's another approach:

#if __GNUC__
  #define program_name program_invocation_name
#else
  char *program_name = "unknown";
#endif

#define SET_PROGRAM_NAME(name) program_name = strdup (name);

Ideally, this should be in a separate module 'program_name' because it
is useful outside of error.

>> malloc: add a #define malloc rpl_malloc which causes code in my
>> package that doesn't need gnulib to break during link.
>
> Here the problem is that some executables need the replacement malloc
> and others don't, buth there's a single config.h for both.
>
> The simplest workaround I can think of for this is to have a separate
> file config1.h like this:
>
>   #include "config.h"
>   #undef malloc
>
> and have the latter apps include config1.h instead.  Admittedly this
> is a hack.

Yes.  I think renaming the glibc compatible malloc to something else,
like Bruno mentioned, is a better idea.  IMHO only modules that fix
pre-C89 function should override C89 functions.

> While we're on the subject, ideally there would be a way for the
> application and for library modules to say something like this: "here
> are the properties I need for malloc: it must never return NULL unless
> it's really out of storage, and it must never allocate SIZE_MAX or
> more bytes".  At link-time, gnulib would select the proper malloc
> wrapper for each application, by taking the union of all the
> requirements.  I don't know of any easy way to implement this,
> unfortunately.

Here is one idea:

1. Fix the malloc module so it doesn't re-define existing
   functionality.  (No module should re-define existing functionality
   IMHO, except for the modules that fix pre-C89 functions.)

2. If the application just want C89 malloc, it does nothing.  If the
   application wants glibc compatible malloc, he does #define malloc
   glibc_malloc.  If the application wants a malloc that never return
   NULL, he does #define malloc xmalloc.

3. If a gnulib module wants a glibc compatible malloc, it depends on
   the new "glibc_malloc" module, and does #define malloc
   glibc_malloc.  Etc.

4. The gnulib modules that implements the malloc variants should start
   by #ifdef malloc #undef malloc #endif, and then possibly add
   #define malloc glibc_malloc if, say, the xmalloc module require a
   glibc malloc.

I didn't think much, so there may be serious flaws.

>> unlocked-io (included implicitly by several modules): claims to be
>> thread unsafe.
>
> gnulib currently assumes unithreaded apps.  I agree that this should
> change.  The simplest fix would be alter unlocked-io so that
> "unlocked-io.h" does nothing for multithreaded apps.  This is pretty
> easy to do by hand (just have an empty unlocked-io.h in your app)
> but it should be easier.

Yes.  Frankly, i don't really understand the point of unlocked-io.  Is
it just optimization?  No functionality improvement?  Is it worth the
added complexity?

>> alloca.c: depends on xmalloc, which I don't always want to use
>> (especially if just copy the file and use AC_FUNC_ALLOCA).
>
> Come to think of it, perhaps that dependency should be removed.  After
> all, ordinary alloca just dumps core if you run out of stack space.
> If the replacement alloca returns NULL when it runs out of space,
> that's a reasonable equivalent.  Does anyone have any objection to
> removing this dependency?  (I introduced this dependency, and I now
> see that I didn't really need to.  Sorry.)

This would be one example where it might be nice to parametrize the
behaviour.  If I use xmalloc in my package, I would probably want
alloca to use xmalloc, but if I don't use xmalloc I probably wouldn't
want alloca to use it.  I can't think of any clean way to parametrize
things that doesn't decrease code readability except having two files,
alloca-malloc.c and alloca-xmalloc.c that was copied to alloca.c
during build depending on the preferences.  Different part of a
package might have different requirements too, but that might be out
of scope for now.

(Example for the last point: I want the libgsasl library to be C89
clean for simplified portability, but in the gsasl command line
interface there is no point in not using everything I can get from
gnulib.  I have roughly the same situation in libidn, shishi and
gsslib as well.)

>> getopt: depends on gettext which adds ~15 additional files even if I
>> don't use gettext.
>
> You can work around this by hand, by merely including lib/gettext.h
> and ignoring all the rest of those files.  (This should be easier to
> do, admittedly.)

Right.  But it imply manual labor each time I update gnulib files
(which, btw, I do by running './gnulib-tool --create-testdir
--dir=/tmp/testdir module1 ...' and then copy m4/* and lib/* from
/tmp/testdir, and the configure.ac snippet, into my project.)