getopt: How to know whether to pass char ** or char *const*?

2007-10-25 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, How best do I determine in my code whether I'm using gnulib's getopt_long, or the system library (potentially glibc)'s? That is, I want to know whether I ought to be passing in a char ** or a char*const*, whilst avoiding warnings and the like.

Re: [PATCH] Added note for translators to gai_strerror.c, so they don't translate param names.

2007-10-25 Thread Bruno Haible
Eric Blake wrote: > Would it perhaps be worth rendering this as: > > _("`Servname' not supported for `ai_socktype'") > > further emphasizing the literalness of the parameter names? IMO, this goes against the sense of quotes: Quoting usually highlights a literal value, not a variable name. If a f

Re: [PATCH] Added note for translators to gai_strerror.c, so they don't translate param names.

2007-10-25 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric Blake wrote: > According to Micah Cowan on 10/25/2007 10:13 AM: >> +/* TRANSLATORS: Servname and ai_socktype are formal parameter names, >> + and should not be translated. */ >> { EAI_SERVICE, N_("Servname not supported for ai_soc

Re: [PATCH] Added note for translators to gai_strerror.c, so they don't translate param names.

2007-10-25 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Micah Cowan on 10/25/2007 10:13 AM: > +/* TRANSLATORS: Servname and ai_socktype are formal parameter names, > + and should not be translated. */ > { EAI_SERVICE, N_("Servname not supported for ai_socktype") }, Would it perh

[PATCH] Added note for translators to gai_strerror.c, so they don't translate param names.

2007-10-25 Thread Micah Cowan
--- ChangeLog |6 ++ lib/gai_strerror.c |2 ++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3ed561c..1fdf097 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2007-10-25 Micah Cowan <[EMAIL PROTECTED]> + + * lib/gai_s

Re: Tru64 4.0D declares round* but does not define them

2007-10-25 Thread Ben Pfaff
Bruno Haible <[EMAIL PROTECTED]> writes: > Ralf Wildenhues wrote: >> On Tru64 4.0D, /usr/include.dtk/math.h declares round, roundf and >> roundl, but I can't find a library that defines them. Same thing for >> roundf and roundl and respective tests. >> >> This causes link failures for the test-r

Re: Errors in the coreutils-6.9 PO file

2007-10-25 Thread Andreas Schwab
Simon Josefsson <[EMAIL PROTECTED]> writes: > Eric Blake <[EMAIL PROTECTED]> writes: > >> According to Clytie Siddall on 10/24/2007 2:37 AM: >>> >>> 2. >>> >>> #: lib/gai_strerror.c:52 >>> msgid "Servname not supported for ai_socktype" >>> >>> "Servname" is ambiguous: "Service name" or "Server

Re: updated Gnulib web page to use latest GNU boilerplate

2007-10-25 Thread Simon Josefsson
[EMAIL PROTECTED] (Karl Berry) writes: > Simon, Eric -- if you would like to be dubbed official maintainers of > gnulib, let me know and I will ask rms to do so. I trust none of the > present maintainers object (I surely don't). I also don't see that it > makes a practical difference in this cas

Re: Errors in the coreutils-6.9 PO file

2007-10-25 Thread Simon Josefsson
Eric Blake <[EMAIL PROTECTED]> writes: > According to Clytie Siddall on 10/24/2007 2:37 AM: >> >> 2. >> >> #: lib/gai_strerror.c:52 >> msgid "Servname not supported for ai_socktype" >> >> "Servname" is ambiguous: "Service name" or "Server name"? You may well >> get inaccurate translations. > >

Re: Tru64 4.0D declares round* but does not define them

2007-10-25 Thread Bruno Haible
Ralf Wildenhues wrote: > On Tru64 4.0D, /usr/include.dtk/math.h declares round, roundf and > roundl, but I can't find a library that defines them. Same thing for > roundf and roundl and respective tests. > > This causes link failures for the test-round* tests: Confirmed. It affects only round*.

Re: Sync maintainer-makefile files

2007-10-25 Thread Jim Meyering
Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> Simon Josefsson <[EMAIL PROTECTED]> wrote: >>> Anyway, I think it should be up to the coreutils maintainers what to do >>> here. >> >> If someone is interested in proposing small patches to coreutils' >> Make

Re: Sync maintainer-makefile files

2007-10-25 Thread Simon Josefsson
Jim Meyering <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Anyway, I think it should be up to the coreutils maintainers what to do >> here. > > If someone is interested in proposing small patches to coreutils' > Makefile.maint, in an attempt to unify things, without r