Re: [PATCH] Describe which environment variables really control the interpretation of the response to -ok.

Hi Jim, > The only non-POSIX behaviour is that it fetches the yesexpr and noexpr from > a compiled PO file rather than from the system's nl_langinfo function. Here is a proposed compromise that enables the strict POSIX behaviour when POSIXLY_CORRECT is set. This is a POSIX compliance fix for the

Re: [PATCH] Describe which environment variables really control the interpretation of the response to -ok.

James Youngman wrote: > The attached patch updates the findutils documentation to more > correctly explain the relationship between the environment and the > behaviour of rpmatch(). However, since I note that other > POSIX-defined tools should also heed LC_COLLATE (cp, for example) I'm > copying t

Re: stat-time test on mingw

Bruno Haible <[EMAIL PROTECTED]> wrote: > The stat-time test fails for three reasons on mingw: ... > 2008-04-27 Bruno Haible <[EMAIL PROTECTED]> > > * modules/stat-time-tests (Depends-on): Add sleep. > * tests/test-stat-time.c (force_unlink): New function. > (cleanup): Use it. >

Re: new snapshot, and a huge set of coreutils test results

Here's a closer look to the tests from gnulib: > go.2008.04.14.07.01.55.log:FAIL: test-frexpl IRIX 6.5, gcc 3.4.3, NaN > argument > go.2008.04.14.07.01.55.log:FAIL: test-isnanl-nolibmsame > go.2008.04.14.07.01.55.log:FAIL: test-vasprintf-posix same Apparently isnanl (0.0L / 0.0L) yield

[PATCH] Describe which environment variables really control the interpretation of the response to -ok.

The attached patch updates the findutils documentation to more correctly explain the relationship between the environment and the behaviour of rpmatch(). However, since I note that other POSIX-defined tools should also heed LC_COLLATE (cp, for example) I'm copying this to the gnulib mailing list.

stat-time test on mingw

Hi Jim, The stat-time test fails for three reasons on mingw: 1) It uses the function sleep(), which does not exist. Fix: Simply use the 'sleep' module. 2) When run for the second time, opening the test files (t-stt-stamp1 etc.) fails, because these files were not cleaned up by the previous

yesno test on mingw

The test-yesno.sh test fails on mingw, for two reasons: 1) It compares output produced with CR/LFs to an expected output with just LFs. 2) The repositioning of the stdin file descriptor at the end of the program is not correct. The test case has an input file of 5 lines: ==

isfinite: fix bugs

On mingw, the test-isfinite test failed: test-isfinite.c:169: assertion failed FAIL: test-isfinite.exe And after adding the same tests as for isnan(long double) - namely, that signalling NaNs, pseudo-denormals and the like be considered as NaNs, not as finite numbers - the test failed also Li

Re: memrchr speed

Also, the memrchr module does not support the renaming in config.h that is used to guarantee namespace cleanliness of shared libraries. E.g. #define memrchr libfoo_memrchr Fixed like this: 2008-04-27 Bruno Haible <[EMAIL PROTECTED]> Allow local renaming in config.h. * lib/me

Re: memrchr speed

Eric Blake wrote: > And to memrchr like this: Good point, the variable 'i' should better be unsigned, to avoid gcc warnings. 2008-04-27 Bruno Haible <[EMAIL PROTECTED]> * lib/memchr.c (__memchr): Change type of 'i'. * lib/memchr2.c (memchr2): Likewise. --- lib/memchr.c.orig