[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: drop unlocked-io dependency in getline module?
From: |
Simon Josefsson |
Subject: |
[Bug-gnulib] Re: drop unlocked-io dependency in getline module? |
Date: |
Fri, 21 Nov 2003 06:02:21 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
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.)
- [Bug-gnulib] drop unlocked-io dependency in getline module?, Simon Josefsson, 2003/11/20
- Re: [Bug-gnulib] drop unlocked-io dependency in getline module?, Karl Berry, 2003/11/20
- Re: [Bug-gnulib] drop unlocked-io dependency in getline module?, Bruno Haible, 2003/11/20
- [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Simon Josefsson, 2003/11/20
- Re: [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Jim Meyering, 2003/11/20
- Re: [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Paul Eggert, 2003/11/20
- [Bug-gnulib] Re: drop unlocked-io dependency in getline module?,
Simon Josefsson <=
- [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Paul Eggert, 2003/11/24
- [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Simon Josefsson, 2003/11/24
- [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Paul Eggert, 2003/11/24
- [Bug-gnulib] Re: malloc wrappers, Bruno Haible, 2003/11/24
- [Bug-gnulib] Re: malloc wrappers, Paul Eggert, 2003/11/24
- Re: [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Bruno Haible, 2003/11/24
- Re: [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Paul Eggert, 2003/11/24
- Re: [Bug-gnulib] Re: drop unlocked-io dependency in getline module?, Bruno Haible, 2003/11/20
Re: [Bug-gnulib] drop unlocked-io dependency in getline module?, Karl Berry, 2003/11/20