Colin Watson wrote:
> I think the attached patch is right (I tested it with LIBS=-lstrsignal
> after installing a bogus /usr/lib/libstrsignal.a with a strsignal
> function that always returns NULL), but would appreciate review from
> those more fluent in Autoconf than I am.
Thanks for the fast wor
On Mon, Jan 14, 2008 at 11:45:17PM +0100, Bruno Haible wrote:
> The mention of a file "strsignal.h" is wrong; I'm fixing it like this:
A vestige of an earlier version of the module. Thanks for spotting it.
--
Colin Watson [EMAIL PROTECTED]
On Tue, Jan 15, 2008 at 12:28:55AM +0100, Bruno Haible wrote:
> You fixed the first portability problem: the function is missing on some
> platforms. But there is another one.
>
> I want to use the replacement in GNU clisp, so I did "man strsignal", and it
> says:
>
>"On some systems (but
Colin Watson wrote:
> I use strsignal in man-db, and would like a Gnulib module to cope with
> its portability problems.
You fixed the first portability problem: the function is missing on some
platforms. But there is another one.
I want to use the replacement in GNU clisp, so I did "man strsigna
> I've attached an updated patch.
The mention of a file "strsignal.h" is wrong; I'm fixing it like this:
2008-01-14 Bruno Haible <[EMAIL PROTECTED]>
* modules/strsignal (Include): Change to .
*** modules/strsignal.orig 2008-01-14 23:43:15.0 +0100
--- modules/strsignal
Colin Watson wrote:
> it just occurred to me that there's no real
> reason to use the snprintf-posix module here; plain snprintf will do
> just fine and is much more lightweight.
Yes, sure.
> I've attached an updated patch.
Thank you. I've applied it.
Bruno
On Wed, Jan 09, 2008 at 10:52:01AM +0100, Bruno Haible wrote:
> Colin Watson wrote:
> > The attached updated patches address your concerns and Paul's
>
> Thanks; looks better now. Two points still:
>
> - This code will not compile with C89 compilers on platforms without
> threading, due to the
Colin Watson wrote:
> The attached updated patches address your concerns and Paul's
Thanks; looks better now. Two points still:
- This code will not compile with C89 compilers on platforms without
threading, due to the semicolon:
strsignal (int signum)
{
__libc_once_define (static, onc
Colin Watson wrote:
> > The set of signals that are supported everywhere is very small, namely:
> > SIGINT
> > SIGILL
> > SIGFPE
> > SIGSEGV
> > SIGTERM
> > SIGABRT
>
> I should have looked at C99 before asking.
That's one half of the research. The other half was to look at what the
s
On Tue, Jan 08, 2008 at 02:42:24AM +0100, Bruno Haible wrote:
> Colin Watson wrote:
> > Do you happen to know whether I was overdoing it by adding in #ifdefs
> > for SIGHUP, SIGINT, etc.? I decided better safe than sorry, but didn't
> > know whether there was some basic set of signals that Gnulib's
On Tue, Jan 08, 2008 at 01:56:55AM +0100, Bruno Haible wrote:
> Colin Watson wrote:
> > I use strsignal in man-db, and would like a Gnulib module to cope with
> > its portability problems. Here's one which seems to be doing the right
> > thing for me so far. This is my first attempt at writing a Gn
Bruno Haible <[EMAIL PROTECTED]> writes:
> It's a moving target, but it can be defined roughly like this:
> - All platforms with a Unix like API, that are not older than ca. 6 years.
> This leads approximately to this list:
> glibc >= 2.1, MacOS X >= 10.2, FreeBSD >= 4.8, NetBSD >= 3.0
Micah Cowan wrote:
> Is there a general guideline for what constitutes "Gnulib's supported
> platforms"?
It's a moving target, but it can be defined roughly like this:
- All platforms with a Unix like API, that are not older than ca. 6 years.
This leads approximately to this list:
glib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
> Colin Watson wrote:
>> Do you happen to know whether I was overdoing it by adding in #ifdefs
>> for SIGHUP, SIGINT, etc.? I decided better safe than sorry, but didn't
>> know whether there was some basic set of signals that Gnulib
Colin Watson wrote:
> Do you happen to know whether I was overdoing it by adding in #ifdefs
> for SIGHUP, SIGINT, etc.? I decided better safe than sorry, but didn't
> know whether there was some basic set of signals that Gnulib's supported
> platforms were guaranteed to have.
You were right. The s
Colin Watson wrote:
> I use strsignal in man-db, and would like a Gnulib module to cope with
> its portability problems. Here's one which seems to be doing the right
> thing for me so far. This is my first attempt at writing a Gnulib module
> from scratch, so I'd appreciate any comments, style or o
On Mon, Jan 07, 2008 at 01:06:38PM -0800, Paul Eggert wrote:
> Thanks for tackling this. My kneejerk reaction: as a general rule, we
> prefer the differences between gnulib and the GNU C library to be
> localized to small sections of the code, and protected by #if !_LIBC,
> the idea being that ide
Thanks for tackling this. My kneejerk reaction: as a general rule, we
prefer the differences between gnulib and the GNU C library to be
localized to small sections of the code, and protected by #if !_LIBC,
the idea being that ideally the gnulib and GNU C Library versions can
be identical. Please
I use strsignal in man-db, and would like a Gnulib module to cope with
its portability problems. Here's one which seems to be doing the right
thing for me so far. This is my first attempt at writing a Gnulib module
from scratch, so I'd appreciate any comments, style or otherwise.
The main practica
19 matches
Mail list logo
