Re: bug#9140: Coreutils Bug on OSX 10.7 (Lion)

2011-07-24 Thread Paul Eggert
On 07/24/11 14:59, Bruno Haible wrote: > +dnl Enable large-file support. This has the effect of changing the size > +dnl of field f_blocks in 'struct statfs' from 32 bit to 64 bit on > +dnl MacOS X >= 10.5 (32-bit mode), allowing file systems >= 4 TiB to be > +dnl found. > +AC_REQUIRE([AC_SYS_LARG

Re: [PATCH] largefile: add dependencies to this module

2011-07-24 Thread Paul Eggert
On 07/24/11 13:27, Bruno Haible wrote: > I don't see the reasoning for adding the dependency to modules > like 'acl', 'javacomp' and 'same'. I'll address these examples below. > If you are adding a dependency to these modules, it sounds like > every piece of application code that

Re: [PATCH] test-select.h: avoid warning from gcc's -Wmissing-declarations

2011-07-24 Thread Jim Meyering
Jim Meyering wrote: > coreutils' "make check" started failing like this > with the latest from gnulib: > > In file included from test-select.c:30:0: > test-select.h:365:1: error: no previous declaration for 'test_function' > [-Werror=missing-declarations] > cc1: all warnings being tre

RE: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and later.

2011-07-24 Thread Voelker, Bernhard
Paul Eggert wrote: > On 07/24/11 22:59, Voelker, Bernhard wrote: > >>> #ifndef _ALL_SOURCE >>> # undef _ALL_SOURCE >>> #endif >>> +/* Enable general extensions on MacOS X. */ >>> +#ifndef _DARWIN_C_SOURCE >>> +# undef _DARWIN_C_SOURCE >>> +#endif >> >> maybe it's too early in the morning for

Re: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and later.

2011-07-24 Thread Paul Eggert
On 07/24/11 22:59, Voelker, Bernhard wrote: >> #ifndef _ALL_SOURCE >> # undef _ALL_SOURCE >> #endif >> +/* Enable general extensions on MacOS X. */ >> +#ifndef _DARWIN_C_SOURCE >> +# undef _DARWIN_C_SOURCE >> +#endif > > maybe it's too early in the morning for me ... but isn't this a NOP: > "

RE: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and later.

2011-07-24 Thread Voelker, Bernhard
Paul Eggert wrote: > diff --git a/m4/extensions.m4 b/m4/extensions.m4 > index 1330503..22156e0 100644 > --- a/m4/extensions.m4 > +++ b/m4/extensions.m4 > @@ -1,4 +1,4 @@ > -# serial 9 -*- Autoconf -*- > +# serial 10 -*- Autoconf -*- > # Enable extensions on systems that normally disable them. >

Re: [PATCH] test-select.h: avoid warning from gcc's -Wmissing-declarations

2011-07-24 Thread Bruno Haible
Jim Meyering wrote: > -int > +static int > test_function (select_fn my_select) Yes please. That's fine. Bruno -- In memoriam Ezechiele Ramin

Re: bug#9140: Coreutils Bug on OSX 10.7 (Lion)

2011-07-24 Thread Bruno Haible
Paul Eggert wrote: > * m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Reject statvfs > implementations that use only 32 bits to count blocks. Dealing with the statvfs() / statfs() calls is one thing. But 'df' also relies on the 'mountlist' module, which on MacOS X uses the function getmntinfo(). This funct

[PATCH] test-select.h: avoid warning from gcc's -Wmissing-declarations

2011-07-24 Thread Jim Meyering
coreutils' "make check" started failing like this with the latest from gnulib: In file included from test-select.c:30:0: test-select.h:365:1: error: no previous declaration for 'test_function' [-Werror=missing-declarations] cc1: all warnings being treated as errors I'll push this in

Re: git, rebase, and ChangeLog

2011-07-24 Thread Bruno Haible
Hi Paul, > > when you rebased your proposed commits, the ChangeLog entries did not go > > in at the top. Are you using the 'git-merge-changelog' driver? > > No, I used "git rebase -i", generated a revised patch, and then > applied it with "git am". Hmm, it may be that the merge driver would not

Re: bug#9140: fsusage: add large volume support on AIX

2011-07-24 Thread Jim Meyering
Bruno Haible wrote: > Paul Eggert wrote: >> Your patches look good to me too. > > Thanks for the review. I've pushed the 3 patches now. > > You can add a coreutils/NEWS entry that says: > > 'df' now supports volumes larger than 4 TiB on MacOS X 10.5 or newer > and on AIX 5.2 or newer. Thanks. I'v

Re: ftell: two minor proposed patches

2011-07-24 Thread Bruno Haible
Hi Paul, > That being said, it may be that you prefer highlighting this particular > conversion because it may narrow the value. Yes, exactly. > if (LONG_MIN <= offset && offset <= LONG_MAX) > return /* (long) */ offset; Fine me me. That's greppable and explains the preceding 'if'. Thanks

Re: [PATCH] largefile: add dependencies to this module

2011-07-24 Thread Bruno Haible
Hi Paul, > This one affects many modules, so I haven't pushed it yet. > The basic idea is that code that uses 'stat (...)' etc. > should always use AC_SYS_LARGEFILE, so that it doesn't > mess up with large files. Plus, the code should use the > up-to-date AC_SYS_LARGEFILE. I agree with the reason

copy_file_preserving variant that doesn't exit on error?

2011-07-24 Thread Reuben Thomas
I just came across the copy-file module, which does exactly what I want (it is even geared to making backup files), but (unfortunately for use in an interactive program) exits on error. I was just wondering what the rationale for this is, rather than returning an error code. Even in a non-interact

Re: bug #17457: "grep -r foo . > somefile" goes into an infinite loop

2011-07-24 Thread Jim Meyering
Paolo Bonzini wrote: > On 07/23/2011 11:12 PM, Jim Meyering wrote: >> >> In my experience, dev/ino is sufficient, as long as you're not using one of >> a few POSIX-violating fringe file systems (clearcase's MVS comes to mind). > > What about a few POSIX-violating fringe operating systems (Windows a

Re: bug #17457: "grep -r foo . > somefile" goes into an infinite loop

2011-07-24 Thread Paolo Bonzini
On 07/23/2011 11:12 PM, Jim Meyering wrote: In my experience, dev/ino is sufficient, as long as you're not using one of a few POSIX-violating fringe file systems (clearcase's MVS comes to mind). What about a few POSIX-violating fringe operating systems (Windows and DJGPP come to mind)? :) Fo

Re: ftell: two minor proposed patches

2011-07-24 Thread Jim Meyering
Paul Eggert wrote: > On 07/24/11 10:25, Bruno Haible wrote: >> I thought about this as well, but it has the drawback that "grep '(long)'" >> wouldn't find this occurrence. > > That's a minor disadvantage. Such a grep is doomed to failure, > as gnulib must have hundreds of conversion to 'long' tha

Re: ftell: two minor proposed patches

2011-07-24 Thread Paul Eggert
On 07/24/11 10:25, Bruno Haible wrote: > I thought about this as well, but it has the drawback that "grep '(long)'" > wouldn't find this occurrence. That's a minor disadvantage. Such a grep is doomed to failure, as gnulib must have hundreds of conversion to 'long' that the 'grep' will miss. Avoi

Re: ftell: two minor proposed patches

2011-07-24 Thread Bruno Haible
Hi Paul, > I thought of making it even more obvious > by adding a comment, like this: > > if (LONG_MIN <= offset && offset <= LONG_MAX) > { >/* Convert offset to the result type 'long', and return. */ >return offset; > } I thought about this as well, but it has the dra

doc: some new glibc functions

2011-07-24 Thread Bruno Haible
The last time the documentation was upgraded for new glibc functions was on 2009-08-22. Time to do it again. I've applied this patch: 2011-07-24 Bruno Haible doc: Mention new glibc headers and functions. * doc/glibc-headers/gshadow.texi: New file. * doc/glibc-functions

Re: ftell: two minor proposed patches

2011-07-24 Thread Paul Eggert
On 07/24/11 03:53, Bruno Haible wrote: > You call it a "wraparound" situation. But there is no arithmetic operation, > just a cast. Isn't there a better word to denote this situation? Sorry, I don't know of one. A cast is an arithmetic operation, though, even though it often has zero runtime cost

Re: ftell: two minor proposed patches

2011-07-24 Thread Bruno Haible
Hi Paul, Good points on both. > @@ -28,8 +29,8 @@ ftell (FILE *fp) > { >/* Use the replacement ftello function with all its workarounds. */ >off_t offset = ftello (fp); > - if (offset == (long)offset) > -return (long)offset; > + if (LONG_MIN <= offset && offset <= LONG_MAX) > +

Re: close depends on fclose?!

2011-07-24 Thread Bruno Haible
> > The assumption was that the vast majority of programs use stdio and > > fclose(). > > But I agree with you, it would be more in line with the gnulib principles > > to let the programmer who needs specific features from fclose() to > > explicitly > > request the 'fclose' module. > > > > Any ob

Re: bug#9140: fsusage: add large volume support on AIX

2011-07-24 Thread Bruno Haible
Paul Eggert wrote: > Your patches look good to me too. Thanks for the review. I've pushed the 3 patches now. You can add a coreutils/NEWS entry that says: 'df' now supports volumes larger than 4 TiB on MacOS X 10.5 or newer and on AIX 5.2 or newer. Bruno -- In memoriam Ezechiele Ramin

ftell: two minor proposed patches

2011-07-24 Thread Paul Eggert
>From 66b4bf9e4933f708a5729f28df5b594c731f9431 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 24 Jul 2011 01:44:03 -0700 Subject: [PATCH 1/2] ftell: do not assume wraparound signed arithmetic * lib/ftell.c: Include . (ftell): Don't assume wraparound signed arithmetic. --- ChangeLog |

[PATCH] * README: Modernize discussion of signed integers.

2011-07-24 Thread Paul Eggert
Assuming overflow wraparound is no longer safe. Mention ones' complement and signed magnitude. --- ChangeLog |6 ++ README| 36 2 files changed, 18 insertions(+), 24 deletions(-) diff --git a/ChangeLog b/ChangeLog index 53a5121..4571ed4 100644 --

[PATCH] largefile: add dependencies to this module

2011-07-24 Thread Paul Eggert
This one affects many modules, so I haven't pushed it yet. The basic idea is that code that uses 'stat (...)' etc. should always use AC_SYS_LARGEFILE, so that it doesn't mess up with large files. Plus, the code should use the up-to-date AC_SYS_LARGEFILE. * m4/mkstemp.m4 (gl_FUNC_MKSTEMP): * m4/te