Re: "unused parameter" warnings

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> However, it would be good to accept patches (at least for gnulib's .h >> files) that mark each unused parameter with __attribute__ ((__unused__)). >> Then, a project that requires use of -Wunused-param

Re: Warnings to be fixed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> +2008-10-16 Jim Meyering <[EMAIL PROTECTED]> >> + >> +openat-die.c: avoid 'no previous prototype' warning >> +* lib/openat-die.c: Include "openat.h". >> +

Re: declare getloadavg in stdlib.h

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > We have been adopting the approach to declare functions provided by glibc > (but not specified by POSIX) in the same header file as glibc does. This > makes sense because most development takes place on glibc systems today. > > The ones that no

Re: mark atexit, memchr, memcmp, memcpy, memmove, memset, raise, rmdir, strcspn, strpbrk as obsolete

Bruno Haible <[EMAIL PROTECTED]> wrote: > The functions atexit, memchr, memcmp, memcpy, memmove, memset, raise, rmdir, > strcspn, strpbrk are all present in systems newer than ca. 1998. They are > not missing in systems as old as AIX 4.3.2, HP-UX 10.20, IRIX 6.2, OSF/1 4.0, > Solaris 2.5.1, Interix

Re: mark atexit, memchr, memcmp, memcpy, memmove, memset, raise, rmdir, strcspn, strpbrk as obsolete

Bruno Haible <[EMAIL PROTECTED]> wrote: >> Gnulib is more than a little about portability. >> Do we really want to discourage creation of packages >> that will work on IRIX 6.1 and AIX older than 4.3.2? > > The systems which don't have atexit() ... raise() are things like > Solaris 2.3, IRIX 5, Sun

Re: declare getusershell in unistd.h

Bruno Haible <[EMAIL PROTECTED]> wrote: >> 2008-10-18 Bruno Haible <[EMAIL PROTECTED]> >> >> * lib/unistd.in.h (getusershell, setusershell, endusershell): New >> declarations. >> * lib/getusershell.c: Include unistd.h. >> * m4/getusershell.m4 (gl_FUNC_GETUSERSHELL): Require >>

Re: getaddrinfo, netdb, canon-host

Jim Meyering <[EMAIL PROTECTED]> wrote: > Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Jim, the canon-host module needs this patch to work with the latest >> changes in the getaddrinfo module. > > Thanks, Simon. > That looks obviously fine. > Please appl

Re: declare lstat in sys/stat.h

Bruno Haible <[EMAIL PROTECTED]> wrote: > lstat() is declared in according to POSIX. Here's a proposed > patch for gnulib to do the same. > > The only tricky issue here is that on some systems we have a > "#define lstat lstat64", and this gets in the way of redefining the function > while at the s

Re: getaddrinfo, netdb, canon-host

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim, the canon-host module needs this patch to work with the latest > changes in the getaddrinfo module. Thanks, Simon. That looks obviously fine. Please apply.

Re: getaddrinfo, netdb, canon-host

Simon Josefsson <[EMAIL PROTECTED]> wrote: ... > I see you already did, thanks. > > There seems to be some lag on gmane's archive of this list, I didn't > receive your reply until now. Yes, I've noticed it on other lists, too, recently. Makes me feel justified for preferring email ;-)

Re: mark atexit, memchr, memcmp, memcpy, memmove, memset, raise, rmdir, strcspn, strpbrk as obsolete

Bruno Haible <[EMAIL PROTECTED]> wrote: ... >> A more conservative approach would be to make each of those >> proposed-obsolete module AC_REQUIRE a new macro with code to run at >> configure-time if ever the module is required. That code could make >> configure fail by default with a diagnostic >

[PATCH] prepare to move selinux-h module to gnulib

FYI, Since this module is useful to augeas <http://augeas.net/>, I've relaxed the license and will soon move it to gnulib. >From 1a13e78ca14dd8b50c00af18d472dee33825560b Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Tue, 21 Oct 2008 15:38:48 +

[PATCH 1/2] selinux-h: new module (from coreutils/gl/)

b0f801c2d1 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Tue, 21 Oct 2008 17:06:17 +0200 Subject: [PATCH 1/2] selinux-h: new module (from coreutils/gl/) * modules/selinux-h: New file. * lib/se-context.in.h: New file. * lib/se-selinux.in.h: New file. * m4/selinux-cont

Re: getgroups: test: =: unary operator expected

ler warning > diff --git a/m4/getgroups.m4 b/m4/getgroups.m4 > index edc2bde..0364752 100644 > --- a/m4/getgroups.m4 > +++ b/m4/getgroups.m4 > @@ -1,9 +1,9 @@ > -#serial 10 > +#serial 11 > > dnl From Jim Meyering. > dnl A wrapper around AC_FUNC_GETGROUPS. &

[PATCH] random_r: new module

I saw that there was no random-number generating module in gnulib, and certainly nothing reentrant, so took glibc's random_r.c and did this: >From bd84b1cb02226a86e36dce4456cd02125d542cb5 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Wed, 22 Oct 2008 11:19:27

Re: selinux-h: two enhancements

David Lutterkort <[EMAIL PROTECTED]> wrote: > These two patches change the new selinux-h module by (1) setting > LIB_SELINUX so that it can easily be linked against (based very closely on > what coreutils does) and (2) add _UNUSED_PARAMETER_ annotation to all the > functions in the stub implementat

Re: [PATCH] random_r: new module

ly. >From a07b7f3a69902d491f7f49ccd5343e20095199a7 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Thu, 23 Oct 2008 14:26:13 +0200 Subject: [PATCH] address Bruno's review feedback --- doc/glibc-functions/initstate_r.texi |6 +++--- doc/glibc-functions/random_r.texi

Re: [PATCH] random_r: new module

Hmph. I posted stale format-patch output. FYI, the actual change *does* add the suggested #include to random_r.c.

Re: obstack: fix license problem

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Simon, > >> Using the obstack module results in warnings: >> >> warning: module obstack depends on a module with an incompatible license: >> exit >> warning: module obstack depends on a module with an incompatible license: >> exitfail >> >> The reason

Re: getgroups: test: =: unary operator expected

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 10/22/2008 9:32 AM: >> To autoconf folks, I've attached the obvious patch below, >> and will push it some time tomorrow if no one objects. >> >> * lib/autoconf/functions.m4 (AC_FUNC_GETGROUPS

Re: [PATCH] random_r: new module

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> If you put a #include inside an extern "C" { ... } block, like this, it >> yields >> a syntax error in C++ mode on some platforms. Better put the #include >> before the extern "C" block, like this: > > I lik

Re: perror: fix license problems

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Using the perror module results in warnings: > > warning: module perror depends on a module with an incompatible license: > intprops > warning: module perror depends on a module with an incompatible license: > strerror > > The reason appears to be beca

[PATCH] sys_socket: fix typo that inhibited expansion of @GNULIB_SEND@

FYI, I've just pushed this: Without it, I'd get link errors on mingw about send_used_without_requesting_gnulib_module_send, even when using that module. diff --git a/ChangeLog b/ChangeLog index b59412e..0bf0c00 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2008-10-24 Ji

Re: perror: fix license problems

T_STRLEN_BOUND to whatever constant >> e.g., INT_STRLEN_BOUND(int64_t) evaluates to. > > Yeah, sizeof fmt + 20 should be enough... libvirt is affected, too, in that it will use strerror, yet is LGPLv2+. Any objection to this? >From 2fea9d6efde41eea3af51b45d27b31ed9f376b52 Mon Sep 1

Re: perror: fix license problems

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> Any objection to this? > > The patch is not needed now that intprops is now LGPLv2+. The comment > would need to be adjusted, though, if you still want to push the patch.

[PATCH] lib/mkdir.c [_WIN32...]: Mark mode as an unused parameter.

I've just pushed this, to avoid a warning on mingw: >From 1056e42fdb8bb68c6afcdcb3a793558cae08ba44 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008 15:28:10 +0200 Subject: [PATCH] * lib/mkdir.c (rpl_mkdir) [_WIN32...]: Mark mode as an unu

gethostname: LGPL -> LGPLv2+

I'd like to use the gethostname module in libvirt (LGPLv2+), for use when building for mingw. Considering the size of the module (trivial, 10-line gethostname function and minimal gethostname.m4), would anyone object to relaxing its license from LGPL to LGPLv2+? This is mainly to avoid gnulib's l

Re: gethostname: LGPL -> LGPLv2+

Jim Meyering <[EMAIL PROTECTED]> wrote: > I'd like to use the gethostname module in libvirt (LGPLv2+), > for use when building for mingw. > > Considering the size of the module (trivial, 10-line gethostname function > and minimal gethostname.m4), would anyone object to r

lstat: LGPLv2+, tempname: depend on lstat

FYI, I've just pushed these two changes. The latter was needed on mingw. >From 3af39f5a9b75a2ca892a19c800cfe27cf0031b00 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Tue, 28 Oct 2008 11:55:43 +0100 Subject: [PATCH 1/2] * modules/lstat (License): Relicense:

gnulib-tool (or something else?) misbehaving...

FYI, I just saw this go by, but don't have time to diagnose it right now: [ BTW, my $TMPDIR is /u/jt503.zc6WFk ] Updating ./gnulib/lib/.gitignore (backup in ./gnulib/lib/.gitignore~) sed: file /u/jt503.zc6WFk/glnfwWQ6/sed-ignore-removed line 2: extra characters after command Creating ./gnu

Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > This patch adds a 'random' module which implements: > > - random > - srandom > - initstate > - setstate > > and replaces: > > - rand > - srand > - RAND_MAX > > It depends on the 'random_r' module. > > random vs random_r > -

Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > On Wed, Oct 29, 2008 at 11:22:08AM +0100, Jim Meyering wrote: > [random, random_r, RAND_MAX] >> However, what if an application wants only random_r? >> We shouldn't require that they import all of the non-th

Re: [PATCH] random_r: new module

t if this annotation might help you, you're welcome to add it. > --- modules/random_r.orig 2008-11-02 19:06:59.0 +0100 > +++ modules/random_r 2008-11-02 19:06:49.0 +0100 > @@ -22,4 +22,4 @@ > LGPLv2+ > > Maintainer: > -Jim Meyering > +Jim Meyering, glibc

Re: [PATCH] Accept Bison's NEWS format.

"Joel E. Denny" <[EMAIL PROTECTED]> wrote: > announce-gen doesn't like Bison's NEWS format. The following patch fixes > it. Or should we consider reformatting Bison's NEWS file? Thanks. > >>From f289ed88ea6513e18709b6b65ea3875bbd375998 Mon Sep 17 00:00:00 2001 > From: Joel E. Denny <[EMAIL PROTE

Re: gnulib and distros

Hi Sylvain, [this thread started here: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/15559 ] Sylvain Beucler <[EMAIL PROTECTED]> wrote: > FYI, Debian apparently does not accept new packages that bundle > gnulib, asking to rebootstrap with their packaged copy instead. > http://packages.debia

glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

Using printf from GNU coreutils newer than 6.9, I get this on rawhide (glibc-2.8.90-16) which looks wrong, but isn't serious: (it shouldn't allocate a 30MB buffer just to fill it with '0's and print it) $ (ulimit -v 2; env MALLOC_PERTURB_=1 printf '%.3000f' 0) printf: write err

Re: unicodeio.c ignores fwrite return value

Jim Meyering <[EMAIL PROTECTED]> wrote: ... >> 2008-11-12 Bruno Haible <[EMAIL PROTECTED]> >> >> * lib/unicodeio.c: Include unistr.h. >> (utf8_wctomb): Remove function. >> (unicode_to_mb): Use utf8_uctomb instead of utf8_wctomb. > &g

[PATCH] tweak lstat.c to avoid mingw link failure

I needed this patch in libvirt to avoid a link error. FYI, there, lstat is pulled in solely via the dependency from tempname. Anyone see a problem with it? >From 96045aad0862b2f6166b41ec51088b7932c2cf6b Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Wed, 12 Nov 2

Re: unicodeio.c ignores fwrite return value

Jim Meyering <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: > ... >>> 2008-11-12 Bruno Haible <[EMAIL PROTECTED]> >>> >>> * lib/unicodeio.c: Include unistr.h. >>> (utf8_wctomb): Remove function. >

Re: unicodeio.c ignores fwrite return value

Bruno Haible <[EMAIL PROTECTED]> wrote: > It's a long time I last looked at the unicodeio module. I'm applying the > changes below, for better integration with gnulib. > >> unicodeio.c: In function 'fwrite_success_callback': >> unicodeio.c:203: warning: ignoring return value of 'fwrite', declar

unicodeio.c ignores fwrite return value

Hi Bruno, unicodeio.c: In function 'fwrite_success_callback': unicodeio.c:203: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result Would you be open to a change that would suppress the above warning? It comes from this: /* Simple success callback that outp

Re: [PATCH] tweak lstat.c to avoid mingw link failure

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I needed this patch in libvirt to avoid a link error. >> * lib/lstat.c: Include *before* the use of stat in >> orig_stat. > > This is not right: On Unix systems on which lstat is not POSIX compli

[PATCH] test-argp-2: avoid test failure when PACKAGE_BUGREPORT is defined

Including gnulib-tests in tar, I hit a spurious failure. This fixes it. >From 6d9934c39304a25f6b45950af4cd8d602f0694e9 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Thu, 13 Nov 2008 11:31:01 +0100 Subject: [PATCH] test-argp-2: avoid test failure when PACKAGE_BUG

Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> It would be good for gnulib to detect the bug and to use >> the replacement snprintf on losing systems. > > Does the "checking whether printf survives out-of-memory conditions" test > from

Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

Bruno Haible <[EMAIL PROTECTED]> wrote: >> > Is the MALLOC_PERTURB_ essential for the failure or not? >> >> It appears to be essential, to ensure that the internal failure >> is manifested. > > Given that > - without MALLOC_PERTURB_, no SIGSEGV occurs, > - early implementations of MALLOC_PERTUR

Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Bruno Haible wrote: >> Jim Meyering wrote: >>> The RHEL bugzilla I mentioned initially is filed against glibc. >>> Or perhaps you meant glibc's own bugzilla? >> >> Yes, that's what I meant: I'm n

Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

Jim Meyering <[EMAIL PROTECTED]> wrote: ... > If it turns out just to be a bug in the implementation of MALLOC_PERTURB_, > then it's not worth the effort to make gnulib work around it. > > However, if it's a real error in glibc's snprintf (as I suspect) -- &g

Re: test-fsync failure on Haiku

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Richard, Jim, > > The test-fsync test is failing on Haiku, at line 40. fsync (stdin), when > stdin refers to a terminal input, simply succeeds on this system. I don't > see anything in POSIX which would mandate a failure of this call. > > OK to make the

Re: MacOSX Leopard gcc-4.2 build problems with coreutils-7.0 and its gnulib

SciFi <[EMAIL PROTECTED]> wrote: ... > I see the snapshot I made a little while ago of gnulib from the > git repo has already fixed this on 2008-10-08, but y'all > apparently don't have this snapshot in your coreutils & findutils > & other projects that use this module (available on the alpha FTP >

[PATCH] gnulib-tool: do not use $(top_srcdir) unquoted; may be tainted

r)'/GNUmakefile [Exit 1] >From 294322566e672fc08dd6f06374912c26e961d27d Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Mon, 24 Nov 2008 17:03:13 +0100 Subject: [PATCH] gnulib-tool: do not emit $(top_srcdir) unquoted; may be tainted * gnulib-to

Re: [PATCH] gnulib-tool: do not use $(top_srcdir) unquoted; may be tainted

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > > * Jim Meyering wrote on Mon, Nov 24, 2008 at 05:09:08PM CET: >> I noticed unquoted uses of $(top_srcdir) in lib/Makefile.am >> and found that gnulib-tool generated them. >> While that's normally not

Re: [PATCH] gnulib-tool: do not use $(top_srcdir) unquoted; may be tainted

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hi Jim, > > * Jim Meyering wrote on Mon, Nov 24, 2008 at 09:02:51PM CET: >> [ along the way I noticed that my gnulib-tool patch is wrong, >> since single quotes in the context of a Makefile dependency >> list are i

Re: Automake and whitespace in pwd

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > > * Jim Meyering wrote on Tue, Nov 25, 2008 at 10:59:36AM CET: >> >> I think it's a fine idea to disallow bogus (and potentially dangerous) >> absolute names in automake's sanity.m4, but the exi

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

s fts.c to expose the d_type information, and the second, in find, to use that newly-available data. Now, on a file system type e.g., ext3 or ext4, that provide usable dirent.d_type, a use like "find . -type d" will stat only the directories. Before, it would stat everything. I'll a

fts: expose dirent.d_type data when possible

As discussed here, http://lists.gnu.org/archive/html/bug-gnulib/2008-11/index.html I've just pushed the following: (one minor difference: updated comments in fts_.h, too) >From 3270695f352a7ff69ba58424329ccbb0f91b47f3 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]

Re: fts: expose dirent.d_type data when possible

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hi Jim, > > sorry for not looking earier. Hi Ralf, Thanks for looking. > * Jim Meyering wrote on Sat, Nov 29, 2008 at 12:00:34PM CET: >> +/* Return the number of bits by which a d_type value must be shifted >> + le

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

"James Youngman" <[EMAIL PROTECTED]> wrote: > On Fri, Nov 28, 2008 at 7:19 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > > First, many thanks for looking at this! > > >> +/* Map the dirent.d_type value, DTYPE, to the corresponding stat.st_mode >>

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

"James Youngman" <[EMAIL PROTECTED]> wrote: >> +static void >> +set_stat_type (struct stat *st, unsigned int dtype) >> +{ >> + mode_t type; >> + switch (dtype) >> +{ >> +case DT_BLK: >> + type = S_IFBLK; >> + break; >> +case DT_CHR: >> + type = S_IFCHR; >> + break;

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

variable. --- ChangeLog |4 lib/fts.c |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9a4ae1f..b6ce284 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2008-11-29 James Youngman <[EMAIL PROTECTED]> + + * lib/fts.c

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

Jim Meyering <[EMAIL PROTECTED]> wrote: > "James Youngman" <[EMAIL PROTECTED]> wrote: >> As far as I can see, the variable type is assigned in the function >> above, but never used. Did you mean to use "type" rather than >> "dtype" i

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

Jim Meyering <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: >> "James Youngman" <[EMAIL PROTECTED]> wrote: >>> As far as I can see, the variable type is assigned in the function >>> above, but never used. Did you mean

[PATCH] unicodeio.c: mark unused parameters

e_callback': unicodeio.c:185: warning: unused parameter 'msg' Ok to avoid the warnings by marking them, as follows? >From 7d016b9419b433fc3ac7736aaae08815dd189c08 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Sat, 29 Nov 2008 17:42:45 +0100 Subje

[PATCH] posixtm.c: avoid a warning

FYI, I remove the following if-lint code, since it is no longer needed (with gcc4), and in fact would provoke its own warning. >From 37bc76801091560c6f1be54925d2942c0f66912a Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Sun, 7 Dec 2008 18:47:02 +0100 Subjec

two tiny changes

I'll push these pretty soon. >From 8cac94365d8b5e8fb84089cb90523adcfb96fb71 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Tue, 2 Dec 2008 17:29:25 +0100 Subject: [PATCH 1/2] * build-aux/announce-gen (get_tool_versions): Accept .xz tarballs. --- build-au

Re: fts: expose dirent.d_type data when possible

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> +case DT_LNK: >> + type = S_IFLNK; >> + break; > ... >> +case DT_SOCK: >> + type = S_IFSOCK; >> + break; >

Re: fts: expose dirent.d_type data when possible

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> Thanks for the report. >> How about this? > > Works fine here, thanks! Thanks for the confirmation. Pushed.

Re: Fix sed script reading maint.mk.

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello all, > > OK to apply? Or would you rather have the $(srcdir)/ in $(ME)? Hi Ralf, That's fine by me, modulo the long line. How about splitting it? syntax-check-rules := \ $(shell sed -n 's/^\(sc_[a-zA-Z0-9_-]*\):.*/\1/p' $(MYSELF)) I have a

a good pdf-to-text converter? [Re: POSIX 2008 available

Eric Blake <[EMAIL PROTECTED]> wrote: > POSIX 2008 is now freely available at: > > http://www.opengroup.org/bookstore/catalog/c082.htm > > which, once you accept a cookie, redirects to: > > http://www.opengroup.org/onlinepubs/9699919799/toc.htm > > [My favorite page - the new examples section for t

AC_HEADER_ASSERT: don't say assertions are disabled when they're not

clearer that it's a two-test use of AS_IF. If no one objects, I'll push in a few hours: [gnulib's gl_ASSERT will get a similar change, included below] >From 27d44bf831cdf696049e2d6a96173d8ea0fa40eb Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date:

Re: a good pdf-to-text converter? [Re: POSIX 2008 available

Ben Pfaff <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> Do any of you know of a pdf-to-text converter that is better than >> pdftotxt? pdftotxt does not preserve line breaks, table formatting, >> displayed code, etc. Even the offi

Re: make m4 use gnulib's maintainer-makefile

Simon Josefsson wrote: > Eric Blake writes: >> Coreutils seems like it may be the better project to drive this effort >> of trying to merge its maint.mk with gnulib, in order to provide a >> single maint.mk file useful across multiple projects. > > Ok. How many are using maint.mk from gnulib? M

Re: POSIX 2008 available, openat

Bruno Haible wrote: > Part 4: New functions. > > Jim, some of these functions (fchmodat, fchownat, fdopendir, fstatat, mkdirat, > openat, unlinkat) are provided by gnulib module 'openat'. Others (faccessat, > linkat, mkfifoat, mknodat, readlinkat, renameat, symlinkat, utimensat) are > not. > What

Re: how do I check that an FD is open?

Sam Steingold wrote: > How do I figure out if the fd (specifically, stdin=0) is open? > apparently it is closed when the application is run by nohup. > the only thing I could figure out so far is fstat: when 0 is open, > st_mode is 8592, when it is closed it is 8630... Hi Sam, This is very light

Re: POSIX 2008 available, openat

Bruno Haible wrote: >> openat emulation depends on save-cwd (GPL), which can call xgetcwd (GPL), >> which >> in turn can call xalloc_die (GPL)? > > openat() and the related system calls are not supposed to signal errors by > themselves and exit the program. Is it possible to restructure the code

Re: POSIX 2008 available, openat

"James Youngman" wrote: > On Mon, Dec 15, 2008 at 12:18 AM, Bruno Haible wrote: >> However, for openat-die.c I don't see a good replacement. In particular, I >> don't see a way how openat_restore_fail() could be handled in library code. >> A program cannot simply continue when its current directo

Re: [PATCH] gitlog-to-changelog pass args to git-log

William Pursell wrote: > This is a simple modification to gitlog-to-changelog > that allows arguments to be passed to git-log > to allow finer control over construction > of the ChangeLog. The intended use case is to allow > a ChangeLog to be built for a branch without requiring > that branch to

Re: git-log chronology in gitlog-to-changelog

William Pursell wrote: > I recall having an issue with git 1.4 in which > git log did not produce correct chronology, > and rpm would reject ChangeLogs generated from > git log because they were out of order. I cannot > duplicate that problem with modern git, but I > notice in the mailing list ar

Re: [PATCH] gitlog-to-changelog pass args to git-log

William Pursell wrote: ... > -Convert git log output to ChangeLog format. > +Convert git log output to ChangeLog format. If present, any ARGS > +are passed to git-log. To avoid ARGS being parsed as options to Thanks. I've pushed that, with only the tiny change: s/git-log/"git log"/ and an updat

Re: automatically preventing merge commits on master

Bruno Haible wrote: > Hi Jim, > > On 2008-10-13 you wrote: >> Does anyone object to my installing a server-side hook >> that would prevent pushing merge commits on master? >> In our experience here (with gnulib.git), pushing a merge >> commit is always unintentional. > > The one that I pushed toda

Re: statvfs on glibc platforms

Bruno Haible wrote: > Hi Jim, > > The Haiku port prompted me to look at this comment. Looking at the sources of > statvfs() for the various glibc platforms, I found that it's not BeOS which > is special, but Linux: It's only the Linux specific implementation which looks > at /proc/mounts. OK to c

[PATCH] inttostr.c: suppress a warning

Hi Paul, Any objection to this change? >From b6459ede3601010abe11e5e2b766e010e1efce5d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 30 Nov 2008 17:36:15 +0100 Subject: [PATCH] inttostr.c: suppress a warning * lib/inttostr.c: Use #pragma GCC diagnostic ignored "-Wtype-limits&qu

Re: support for universal binaries on MacOS X (5/6)

Bruno Haible wrote: > The configure test whether mktime works produces the result "yes" in 32-bit > mode and "no" in 64-bit mode. In universal builds, we cannot manage these > different results (it would become a #ifdef mess). Therefore I propose to > combine the results to "no". OK to commit? Hi

Re: support for universal binaries on MacOS X (5/6)

f test $AIX_UNIVERSAL_BUILD = 1; then etc. Then the nesting/logic of the majority of lines in that file doesn't change. diff --git a/m4/mktime.m4 b/m4/mktime.m4 index 5faf393..b1884f5 100644 --- a/m4/mktime.m4 +++ b/m4/mktime.m4 @@ -15,6 +15,13 @@ dnl From Jim Meyerin

Re: support for universal binaries on MacOS X (5/6)

Bruno Haible wrote: ... >> It looks to me like the change below is equivalent to yours, > > Ah, I see now what you mean. Fine with me. > > I wouldn't have chosen this solution because it tears apart the > determination of the ac_cv_func_working_mktime into two parts, > one before the AC_CACHE_CHEC

[PATCH 3/3] find: take advantage of new gnulib/fts leaf-optimization

t takes only 80 seconds (2.6.26, athlon64 3400+, 2yr-old disk), while using the latest unmodified find, at over 16 minutes, it takes 12 times as long. I'll post again when I have an fts patch implementing the approach outlined above. >From 5ca0d569635c801910c813a9f5c027759bafdf99 Mon Sep

sed, SIGPIPE, cmp -s [Re: [PATCH 3/4] gnulib-tool: abort loops early where possible.

Ralf Wildenhues wrote: > * gnulib-tool (func_modules_add_dummy, func_emit_lib_Makefile_am) > (func_emit_tests_Makefile_am, func_import): Abort loops early if > we already know the answer. Hi Ralf, Not that I've reviewed it in detail, but this looks ok. Also, it induces no change in coreutils bui

[PATCH] improve M4 quoting

644 --- a/configure.ac +++ b/configure.ac @@ -18,7 +18,7 @@ dnl Written by Jim Meyering. -AC_PREREQ(2.61) +AC_PREREQ([2.61]) # Make inter-release version strings look like, e.g., v6.9-219-g58ddd, which # indicates that it is built from the 219th delta (in _some_ repository) @@ -27,9 +27,9 @@

more m4 quoting

FYI, now I'm looking at the changes induced by the following: git ls-files | grep '\.m4$' | xargs perl -pi \ -e 's/(AC_[A-Z_]+\()([^[()]+?)([,)])/$1\[$2]$3/g;' \ -e 's/(AC_[A-Z_]+\((?:\[[^,]+?\], ){1})([^,[()]+?)([,)])/$1\[$2]$3/g;' \ -e 's/(AC_[A-Z_]+\((?:\[[^,]+?\], ){2})([^,[()]+?

Re: sed, SIGPIPE, cmp -s [Re: [PATCH 3/4] gnulib-tool: abort loops early where possible.

Bruno Haible wrote: >>./bootstrap: Copying ._bootmp/gnulib-tests/Makefile.am to >> gnulib-tests/gnulib.mk... >> -sed: couldn't write 60 items to stdout: Broken pipe >> +sed: couldn't write 56 items to stdout: Broken pipe >> >> I see that it's technically harmless and comes from here: >> >

Re: Conflicting types for mblen on Solaris 2.6

"Tom G. Christensen" wrote: > The current daily snapshot is failing to build fprintftime: > depbase=`echo fprintftime.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" > -DNO_XMALLOC -DEXEEXT=\"\" -I. -I.. -I../intl -I/usr/tgcware/includ

Re: Conflicting types for mblen on Solaris 2.6

"Tom G. Christensen" wrote: > On Thu, Jan 01, 2009 at 10:11:11PM +0100, Jim Meyering wrote: >> [resend after bounce (my problem)] >> "Tom G. Christensen" wrote: >> > The current daily snapshot is failing to build fprintftime: >> > depba

Re: strftime updates

Bruno Haible wrote: > Also, the test for mempcpy is redundant since nothing uses it. Proposed patch: That looks fine, and you're welcome to apply it. I'm generally in favor of clean-up changes in strftime.c, as long as they're not too invasive. Thinking of merge work, I see that there are some

Re: [PATCH 0/4] faster gnulib-tool

Bruno Haible wrote: > Unfortunately, I don't see a better choice as an implementation language > of gnulib-tool: > - Python is good for text processing but does incompatible changes > in the language definition every couple of years. > - Perl is excluded because of the misdesigned syntax,

Re: bash, sed, SIGPIPE

Bruno Haible wrote: > Eric Blake wrote in > : >> > After 'trap - SIGPIPE', sed should get a fatal SIGPIPE signal in these >> > conditions. >> > Quoting >> >

[PATCH] gnulib-tool: fix sed-based filtering

one objects. >From 8d90fcc8c796b2a3c7696ec4a39105d7a9525903 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 2 Jan 2009 19:29:30 +0100 Subject: [PATCH] gnulib-tool: fix sed-based filtering * gnulib-tool (func_filter_filelist): Remove extra backslash in sed_fff_filter definition. --- gnulib-tool |2

Re: [PATCH] remove duplicate inclusion of

No big deal, but... Ok, Bruno? >From 24cb49400d1349f29f745e74979b5ce45022288f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 30 Nov 2008 17:08:33 +0100 Subject: [PATCH] remove duplicate inclusion of --- tests/test-fprintf-posix.c |1 - tests/test-printf-posix.c|

Re: working with "good enough" functions

Mike Frysinger wrote: > the gnulib implementations of POSIX functions are pretty damn complete. for > most of my uses though, they're *too* complete :). > > for example, current gnulib will often enable printf functions on modern > systems (such as Linux w/glibc 2.9). this is because extended f

Re: support for universal binaries on MacOS X (5/6)

Jim Meyering wrote: > Bruno Haible wrote: > ... >>> It looks to me like the change below is equivalent to yours, >> >> Ah, I see now what you mean. Fine with me. ... Hi Bruno, I've reworked those patches accordingly, but didn't test on a MacOS X system.

Re: choice of implementation language

"Bruno Haible" wrote: > If gnulib-tool was to be rewritten in another programming language than > shell + sed, what would be the good choices? > > The foremost criteria IMO should be the maintainability, i.e. the ability for > us and for new contributors to gnulib to master this programming langua

FYI, getloadavg vs. AIX 6.1

FYI, I applied a tiny patch yesterday. http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=f4871c025a82 Here's the thread: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15465

<    1   2   3   4   5   6   7   8   9   10   >