Re: coreutils-6.3 on MacOS X

Paul Eggert <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> To turn off this warning one needs to pass -Wno-missing-field-initializers. > > OK, but I'm afraid the ship has already sailed with gcc -W on > Coreutils. Coreutils has several other places where gcc -W issues >

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > To turn off this warning one needs to pass -Wno-missing-field-initializers. OK, but I'm afraid the ship has already sailed with gcc -W on Coreutils. Coreutils has several other places where gcc -W issues bogus warnings (typically about signed vs unsigne

Re: coreutils-6.3 on MacOS X

Paul Eggert wrote: > It causes "gcc -Wall" to issue a warning, but you can work around > this by appending -Wno-missing-braces. The warning that this kind of initializer (with or without the trailing comma) elicits with "gcc -W -Wall" on glibc systems is foo.c:3: warning: missing in

Re: coreutils-6.3 on MacOS X

Paul Eggert <[EMAIL PROTECTED]> wrote: ... > This subject has come up a couple of times before. In > > I noted that glibc now sometimes uses the following style when the > type isn't known to be a structure or a scalar: > >

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > Here the problem is: > mbstate_t mbstate = {0}; > ISO C 99 guarantees only that mbstate_t is not an array type; it could > be a scalar or pointer type. But that's OK. The initializer is valid C89 (and C99) even if mbstate_t is a scalar or pointer

Re: coreutils-6.3 on MacOS X

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 10/9/2006 6:40 AM: >>> Why not instead fix stat-macros.h to include ? Then future >>> users of "stat-macros.h" don't have to worry about this portability trap. >> >> Because there have been problems with systems for which >> can

Re: coreutils-6.3 on MacOS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/9/2006 6:40 AM: >> Why not instead fix stat-macros.h to include ? Then future >> users of "stat-macros.h" don't have to worry about this portability trap. > > Because there have been problems with systems for which >

Re: coreutils-6.3 on MacOS X

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 10/9/2006 5:50 AM: >> Thanks. >> I've checked in that change: >> >> 2006-10-09 Jim Meyering <[EMAIL PROTECTED]> >> >> * lchown.c: Include before "stat-macros.h". >> Patch from Bruno Haible. > > Why not instead fix sta

Re: coreutils-6.3 on MacOS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/9/2006 5:50 AM: > Thanks. > I've checked in that change: > > 2006-10-09 Jim Meyering <[EMAIL PROTECTED]> > > * lchown.c: Include before "stat-macros.h". > Patch from Bruno Haible. Why not instead fix st

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> wrote: ... > In file included from lchown.c:26: > stat-macros.h:26:4: #error "you must include before including > this file" > lchown.c: In function `lchown': > lchown.c:37: error: storage size of `stats' isn't known > lchown.c:39: warning: implicit declaration of

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> wrote: > pathchk.c:203: warning: missing braces around initializer > pathchk.c:203: warning: (near initialization for `mbstate.__mbstate8') > > Here the problem is: > mbstate_t mbstate = {0}; > ISO C 99 guarantees only that mbstate_t is not an array type; it c

Re: coreutils-6.3 on MacOS X

Paul Eggert wrote: > > at-func.c:39: warning: implicit declaration of function `lchown' > > dirchownmod.c:102: warning: implicit declaration of function `lchown' > > (lchown is not provided by the system; gnulib's substitute is used.) > > mkstemp-safer.c:34: warning: implicit declaration of functio

Re: coreutils-6.3 on MacOS X

Jim Meyering <[EMAIL PROTECTED]> writes: > http://lists.gnu.org/archive/html/bug-coreutils/2006-09/msg00366.html > That Darwin-7.9.0/NFS/hardlink bug is a nasty one. > I'm not convinced it's worth working around, Ouch!. I agree. The proposed workaround would cause lots of real-world problems

Re: coreutils-6.3 on MacOS X

Paul Eggert <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> On Darwin-7.9.0 with CPPFLAGS=-Wall: Builds fine. All tests pass. The >> "rm -rf" HFS+ bug workaround works fine. The "rm -rf" hardlinks / NFS bug >> is still open. > > I'm not familiar with that one, but suspec

Re: coreutils-6.3 on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > On Darwin-7.9.0 with CPPFLAGS=-Wall: Builds fine. All tests pass. The > "rm -rf" HFS+ bug workaround works fine. The "rm -rf" hardlinks / NFS bug > is still open. I'm not familiar with that one, but suspect that the approach suggested in