[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [Bug-gnulib] Re: drop unlocked-io dependency in getline module?
Date: 20 Nov 2003 12:23:15 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Simon Josefsson <address@hidden> writes:

> Some examples:

Thanks for writing up these examples: you've pointed out important

> 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.

> 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.

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,

> 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.

> 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.)

> 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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]