Re: [PATCH 2/2] strerror: work around FreeBSD bug

On 06/07/2011 05:09 PM, Eric Blake wrote: > On 06/07/2011 03:29 AM, Bruno Haible wrote: >> Eric Blake wrote: >>> * lib/strerror.c (strerror): Special case 0. >> >> Thanks. >> >> On MacOS X 10.5, I'm still seeing these failures: >> >> test-strerror.c:63: assertion failed >> FAIL: test-strerror >

Re: [PATCH 1/2] stat-macros: Enhance to provide block-related information.

It'd be good to add something like this, thanks. A few comments: The time-related stat macros are already broken out into stat-time.h. Perhaps these size-related macros should be broken out into stat-size.h? That way, we could leave stat-macros.h alone. Many programs that need CHMOD_MODE_BITS

[PATCH 1/2] stat-macros: Enhance to provide block-related information.

* lib/stat-macros.h: Insert part of coreutils' system.h, which defines DEV_BSIZE, ST_BLKSIZE, ST_NBLOCKS and ST_NBLOCKSIZE. * modules/stat-macros: Depend on sys_stat (because now stat-macros.h includes sys/stat.h) and stdint (because we need SIZE_MAX). Since the file is now substantially composed

[PATCH 2/2] stat-macros: document the stat-macros module.

* doc/gnulib.texi: Include stat-macros.texi. * doc/stat-macros.texi: Documentation for this module. --- ChangeLog|6 ++ doc/gnulib.texi |4 doc/stat-macros.texi | 31 +++ 3 files changed, 41 insertions(+), 0 deletions(-) create mode

[PATCH 0/2] stat-macros: shared code from coreutils & findutils

GNU findutils uses a section of code shared with coreutils' system.h to implement the -ls action. This particular section of code deals with figuring out the number of blocks in a file, and the units of st_nblocks. Rather than continue to try to keep these bits of code in sync, I propose to move

Re: [PATCH 2/2] strerror: work around FreeBSD bug

On 06/07/2011 03:29 AM, Bruno Haible wrote: > Eric Blake wrote: >> * lib/strerror.c (strerror): Special case 0. > > Thanks. > > On MacOS X 10.5, I'm still seeing these failures: > > test-strerror.c:63: assertion failed > FAIL: test-strerror strerror(0) misbehavior. Hmm, while FreeBSD was s

[PATCH] stat-time: get_stat_birthtime failure is better-defined

* lib/stat-time.h (get_stat_birthtime): If the time is not available, return a timestamp whose tv_sec and tv_nsec values are both -1. Previously, the spec said only that the tv_nsec value was negative. This upward-compatible change simplifies GNU tar a bit. diff --git a/lib/stat-time.h b/lib/stat-t

[PATCH 2/2] strerror_r-posix: work around cygwin 1.7.9

Cygwin __xpg_strerror_r clobbers strerror, until cygwin 1.7.10; in this case, we must replace strerror, but there was nothing in strerror.m4 finding fault with cygwin's native strerror. Solve this by splitting strerror_r.m4 into two parts, one for probing for the strerror_r bug, and one for replac

[PATCH 1/2] test-perror: relax test to ignore cygwin bug

glibc was not the only platform where fprintf(fopen(,"r")) fails to detect errors; cygwin 1.7.9 is another culprit (although it will be fixed for 1.7.10), and I suspect that several other platforms were failing perror2 for the same reason. At this point, there are so many functions affected, and t

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

On 06/06/2011 04:29 PM, Bruno Haible wrote: > Hi all, > > In we > found out that every AC_LIBOBJ invocation must be triggered from a module > that contains the referred file. Otherwise bugs occur. > > The most straightforward an

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

On 06/07/2011 03:07 PM, Stefano Lattarini wrote: >>> So, what is a "hard error"? >> >> Exit status 99 is special to automake - it says quit the testsuite now, >> regardless of how many tests remain >> > Well, no, it means "count this outcome as a failure, even if the testcase is > expected to fail

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

On Tuesday 07 June 2011, Eric Blake wrote: > On 06/07/2011 02:22 PM, Bruno Haible wrote: > > Stefano Lattarini wrote: > >> +fatal_ () { warn_ "$ME_: hard error: $@"; Exit 99; } > > > > What is a "hard error"? > > > > I thought a test could either succeed, or fail, or produce no result due to > >

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

On 06/07/2011 02:22 PM, Bruno Haible wrote: > Stefano Lattarini wrote: >> +fatal_ () { warn_ "$ME_: hard error: $@"; Exit 99; } > > What is a "hard error"? > > I thought a test could either succeed, or fail, or produce no result due to > unexpected circumstances, and this last case was called "fr

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

Stefano Lattarini wrote: > +fatal_ () { warn_ "$ME_: hard error: $@"; Exit 99; } What is a "hard error"? I thought a test could either succeed, or fail, or produce no result due to unexpected circumstances, and this last case was called "framework failure". Quartum non datur. So, what is a "hard

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

On Tuesday 07 June 2011, Jim Meyering wrote: > > Done in the attached patch. If this amended patch is OK, please > > go ahead and apply it, because I don't have pushing right for > > gnulib. > ... > > Subject: [PATCH] tests init: new function 'fatal_', for hard errors > > > > Before this patch, th

Re: [PATCH] tests: fix usage message in 'mktempd_'

On Tuesday 07 June 2011, Eric Blake wrote: > On 06/07/2011 05:57 AM, Stefano Lattarini wrote: > > * tests/init.sh (mktempd_): In the usage message, use literal > > 'mktempd_', not '$ME' (which is even undefined), as the name of > > the subroutine. > > --- > > ChangeLog |7 +++ > > test

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

Stefano Lattarini wrote: > On Tuesday 07 June 2011, Jim Meyering wrote: >> Hi Stefano, >> > Hello Jim, thanks for the quick review. > >> Thanks for the patch. This looks fine, though you might want >> to adjust the commit log and ChangeLog nits: >> >> Stefano Lattarini wrote: >> > Before this patc

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

On Tuesday 07 June 2011, Jim Meyering wrote: > Hi Stefano, > Hello Jim, thanks for the quick review. > Thanks for the patch. This looks fine, though you might want > to adjust the commit log and ChangeLog nits: > > Stefano Lattarini wrote: > > Before this patch, the only way offered by tests/ini

Re: [PATCH] tests: fix usage message in 'mktempd_'

Stefano Lattarini wrote: > * tests/init.sh (mktempd_): In the usage message, use literal > 'mktempd_', not '$ME' (which is even undefined), as the name of > the subroutine. > --- > ChangeLog |7 +++ > tests/init.sh |2 +- > 2 files changed, 8 insertions(+), 1 deletions(-) > > diff

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

On 06/07/2011 05:58 AM, Stefano Lattarini wrote: > Before this patch, the only way offered by tests/init.sh to > properly signal an hard error was the `framework_failure_' > +++ b/tests/init.sh > @@ -77,6 +77,7 @@ Exit () { set +e; (exit $1); exit $1; } > warn_ () { echo "$@" 1>&$stderr_fileno_;

Re: [PATCH] tests init: new subroutine 'fatal_', for hard errors

Hi Stefano, Thanks for the patch. This looks fine, though you might want to adjust the commit log and ChangeLog nits: Stefano Lattarini wrote: > Before this patch, the only way offered by tests/init.sh to > properly signal an hard error was the `framework_failure_' s/an hard/a hard/ > subrouti

Re: [PATCH] tests: fix usage message in 'mktempd_'

On 06/07/2011 05:57 AM, Stefano Lattarini wrote: > * tests/init.sh (mktempd_): In the usage message, use literal > 'mktempd_', not '$ME' (which is even undefined), as the name of > the subroutine. > --- > ChangeLog |7 +++ > tests/init.sh |2 +- > 2 files changed, 8 insertions(+),

[PATCH] tests init: new subroutine 'fatal_', for hard errors

Before this patch, the only way offered by tests/init.sh to properly signal an hard error was the `framework_failure_' subroutine. But the error message issued by that subroutine, as its name would suggest, refers to a set-up failure in the testsuite, while hard errors can obviously also be due to

[PATCH] tests: fix usage message in 'mktempd_'

* tests/init.sh (mktempd_): In the usage message, use literal 'mktempd_', not '$ME' (which is even undefined), as the name of the subroutine. --- ChangeLog |7 +++ tests/init.sh |2 +- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 506a07

Re: [PATCH 2/2] strerror: work around FreeBSD bug

Eric Blake wrote: > * lib/strerror.c (strerror): Special case 0. Thanks. On MacOS X 10.5, I'm still seeing these failures: test-strerror.c:63: assertion failed FAIL: test-strerror test-perror2.c:112: assertion failed FAIL: test-perror2 Bruno -- In memoriam The Jews from the Braslav gh