Re: make -q and maintainer-makefile issues?

On 8/18/2011 4:12 PM, Bruno Haible wrote: > Charles Wilson writes: >> On cygwin, we typically reautotool almost any package, as a routine part >> of building it. > > You are on your own when doing this. This is not the recommended > way to build, explained in the INSTALL file. Ack. > Nevertheles

Re: [PATCH]: Parse ISO 8601 extended date and time of day format

Jim Meyering writes: > I would change two doc-related things: > > [...] > > - I noticed that the new format "T" > is not documented. There's already a sentence or two on the > @sc{iso} 8601 date format. Dare I ask? ... Would you care > to add a few words about the new one? If

Re: Portability issue for error_tail().

On 08/18/2011 06:11 PM, Mats Erik Andersson wrote: >error (EXIT_FAILURE, EPERM, NULL); > > nothing serious will happen on GNU/Linux with Glibc, My kneejerk reaction is that 'error' isn't documented to treat NULL as the empty string, and that portable programs should not pass a NULL format to

Re: Problem with fstatat on AIX 7.1

[Adding bug-gnulib@gnu.org and retitling Subject: for these threads: http://lists.gnu.org/archive/html/bug-tar/2011-08/msg3.html http://lists.gnu.org/archive/html/bug-tar/2011-08/msg5.html ] On 08/18/2011 05:06 PM, Kevin Brott wrote: > So it looks like you're probably on the right track.

Portability issue for error_tail().

Dear all, I have found an exceptional portability issue when building GNU lib for NexentaCore/i386-pc-solaris2.11. Said system lacks the library call error (status, errno, format, ...) which therefore is brought in from GNU lib. However, should a programmer happen to erroneously write e

Re: fts: do not exhaust memory when processing million-entry directory

On 08/18/2011 09:14 PM, Jim Meyering wrote: > Pádraig Brady wrote: >>> With the default threshold of 100,000, the maximum is under 30MB >>> and slightly faster than the first run: > ... >>> 0 >>> +--->Gi >>>0

Re: [PATCH]: Parse ISO 8601 extended date and time of day format

On 08/18/2011 03:12 PM, Jim Meyering wrote: > "parse-datetime.y", line 109: error #79: expected a type specifier > verify (TYPE_IS_INTEGER (time_t)); Thanks. My wild guess is that configure+Coverity is mishandling _Static_assert, which would be amusing given that Coverity is all about

Re: [PATCH]: Parse ISO 8601 extended date and time of day format

Paul Eggert wrote: > On 08/18/2011 02:25 PM, Jim Meyering wrote: >> I had to >> comment out the two verify uses to make coverity succeed in >> analyzing parse-datetime.c > > Dumb question: How does 'verify' break coverity? > Is there a plausible workaround? > (Sorry, I don't use coverity.) I haven

Re: [PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code

Jim Meyering wrote: > Eric Blake wrote: >> On 08/18/2011 07:53 AM, Jim Meyering wrote: >>> From: Jim Meyering >>> >>> --- >>> lib/fts.c | 21 + >>> 1 files changed, 1 insertions(+), 20 deletions(-) >>> >>> diff --git a/lib/fts.c b/lib/fts.c >>> index 7210c1b..c96dd9d 10064

Re: [PATCH]: Parse ISO 8601 extended date and time of day format

On 08/18/2011 02:25 PM, Jim Meyering wrote: > I had to > comment out the two verify uses to make coverity succeed in > analyzing parse-datetime.c Dumb question: How does 'verify' break coverity? Is there a plausible workaround? (Sorry, I don't use coverity.)

Re: [PATCH]: Parse ISO 8601 extended date and time of day format

J.T. Conklin wrote: > Quite a long time ago, I posted a proof of concept change to > parse-datetime.y to enable parsing of ISO 8601 "extended date and time > of day expressions" using a 'T' separator character. > > While waiting for my copyright assignment paperwork to clear, I found > and fixed so

Re: fts: do not exhaust memory when processing million-entry directory

Pádraig Brady wrote: >> With the default threshold of 100,000, the maximum is under 30MB >> and slightly faster than the first run: ... >> 0 >> +--->Gi >>0 4.4

Re: make -q and maintainer-makefile issues?

[Un-CCing the coreutils list.] Charles Wilson writes: > Apparently it can be done -- provided you configure and build in a > specific way. Yes, gettext can be built as documented in the INSTALL file. Only one extra option, --with-included-libxml, is needed on Cygwin. > However, it does not appea

Re: [PATCH 8/8] fts: do not exhaust memory when processing million-entry directories

Paul Eggert wrote: > Thanks for all that work to make fts better! A couple of minor things > about comments: > > On 08/18/2011 06:53 AM, Jim Meyering wrote: > >> + into memory at once. However, When an fts_compar function > > The "However," can be removed (there are too many Buts etc. i

Re: fts: do not exhaust memory when processing million-entry directory

On 08/18/2011 02:53 PM, Jim Meyering wrote: > A few weeks ago, I noticed that removing a directory with very many > entries made rm -rf use an inordinate amount of memory. I've fixed the > underlying fts module to batch its readdir calls in the common case, > thus to imposing a reasonable ceiling

Re: [PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code

Eric Blake wrote: > On 08/18/2011 07:53 AM, Jim Meyering wrote: >> From: Jim Meyering >> >> --- >> lib/fts.c | 21 + >> 1 files changed, 1 insertions(+), 20 deletions(-) >> >> diff --git a/lib/fts.c b/lib/fts.c >> index 7210c1b..c96dd9d 100644 >> --- a/lib/fts.c >> +++ b/li

Re: [PATCH 4/8] maint: fts.c (__opendir2): Remove unused parameter, oflag.

On 08/18/2011 07:53 AM, Jim Meyering wrote: From: Jim Meyering --- lib/fts.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 776dda5..b8b7c5a 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1192,7 +1192,7 @@ set_stat_type (struct stat *st, un

Re: [PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code

On 08/18/2011 07:53 AM, Jim Meyering wrote: From: Jim Meyering --- lib/fts.c | 21 + 1 files changed, 1 insertions(+), 20 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 7210c1b..c96dd9d 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1233,12 +1233,6 @@ fts_build (regi

Re: [PATCH 8/8] fts: do not exhaust memory when processing million-entry directories

Thanks for all that work to make fts better! A couple of minor things about comments: On 08/18/2011 06:53 AM, Jim Meyering wrote: > + into memory at once. However, When an fts_compar function The "However," can be removed (there are too many Buts etc. in the neighborhood already ...)

Re: CLISP does not compile on MinGW with latest gnulib

On 08/18/2011 09:50 AM, Michael Kappert wrote: Hi, When trying to compileCLISP on MinGW, make fails with libgnu.a(regex.o): In function `rpl_regerror': c:\users\michael\repo\clisp\build.test\gllib/../../src/gllib/regcomp.c:559: undefined reference to `libintl_gettext'

CLISP does not compile on MinGW with latest gnulib

Hi, When trying to compileCLISP on MinGW, make fails with libgnu.a(regex.o): In function `rpl_regerror': c:\users\michael\repo\clisp\build.test\gllib/../../src/gllib/regcomp.c:559: undefined reference to `libintl_gettext' libgnu.a(regex.o): In function `rpl_re_compile_p

Re: make -q and maintainer-makefile issues?

On 8/12/2011 1:00 PM, Bruno Haible wrote: > [CCing bug-gettext and Charles Wilson] > Eric Blake wrote in [1]: >> At least cygwin still ships with >> only gettext 0.17, because all versions of 0.18 are unbuildable on the >> current cygwin. > > This is a myth, and is factually wrong. ... > * The

[PATCH 8/8] fts: do not exhaust memory when processing million-entry directories

From: Jim Meyering Before this change, traversing (via rm -rf, find, du, etc.) an N-entry directory would require about 256*N bytes of memory. Thus, it was easy to construct a directory too large to be processed by any of those tools. With this change, the maximum memory utilization is now limi

[PATCH 6/8] fts: add/use new struct member, fts_dirp

From: Jim Meyering We are about to use this to manage any directory with too many entries to read all of them into memory at once. To do that, we'll need to save the DIR* pointer in each affected FTSENT struct. * lib/fts_.h: Include . (struct FTSENT) [fts_dirp]: New member. * lib/fts.c (closedir_

[PATCH 5/8] maint: fts: give __opendir2 a new parameter

From: Jim Meyering * lib/fts.c (__opendir2): Give it a new parameter, Pdir_fd, rather than surreptitiously using sole caller's "dir_fd". --- lib/fts.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index b8b7c5a..33ecffb 100644 --- a/lib/fts.c

[PATCH 7/8] fts: move decl of "dp" into while loop; split long line

From: Jim Meyering --- lib/fts.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 9e935ba..48919f7 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1229,7 +1229,6 @@ static FTSENT * internal_function fts_build (register FTS *sp, int type)

[PATCH 2/8] maint: fts.c: move __opendir2 #define "up" out of function body

From: Jim Meyering --- lib/fts.c | 28 +--- 1 files changed, 13 insertions(+), 15 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index c96dd9d..62ce38f 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1192,6 +1192,17 @@ set_stat_type (struct stat *st, unsigned int dtype)

fts: do not exhaust memory when processing million-entry directory

A few weeks ago, I noticed that removing a directory with very many entries made rm -rf use an inordinate amount of memory. I've fixed the underlying fts module to batch its readdir calls in the common case, thus to imposing a reasonable ceiling on memory usage. The ceiling of ~30MB is reached fo

[PATCH 3/8] maint: fts.c: correct off-by-one indentation

From: Jim Meyering --- lib/fts.c | 49 - 1 files changed, 24 insertions(+), 25 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 62ce38f..776dda5 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1242,38 +1242,37 @@ fts_build (register FTS *sp, int

[PATCH 4/8] maint: fts.c (__opendir2): Remove unused parameter, oflag.

From: Jim Meyering --- lib/fts.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 776dda5..b8b7c5a 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1192,7 +1192,7 @@ set_stat_type (struct stat *st, unsigned int dtype) st->st_mode = type; } -#

[PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code

From: Jim Meyering --- lib/fts.c | 21 + 1 files changed, 1 insertions(+), 20 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 7210c1b..c96dd9d 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1233,12 +1233,6 @@ fts_build (register FTS *sp, int type) * Open the di

Re: [bug-diffutils] [PATCH] Avoid gcc warning on Stratus OpenVOS building regex.c

On 08/17/2011 05:12 PM, Eric Blake wrote: > Wouldn't it just be simpler to always define internal_function as an empty > macro > when not on _LIBC, Yes, I think so. I did that in gnulib, here: http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=a6b16b69fe1cad695b270dd5bf3deb2850fc4dd1 and t