Re: threadlib and emacs

On 07/08/11 18:31, Bruno Haible wrote: > Does that sound feasible? It might work, yes, though it'd need some experimentation. As it happens, I got your email at about the same time that I was asked to stop installing this sort of change into Emacs for now, as it's in feature freeze. At some poi

Re: threadlib and emacs

Hi Paul, > I looked at the current non-threadlib implementation again in the light of > your > comments, and I now think that it goes too far, as it fusses with > LIBS and so forth.  I'd rather have something even simpler. > > I see that you're now working in that area, but > once things have se

Re: [PATCH 03/10] pthread_sigmask: new module

On 07/08/11 14:05, Bruno Haible wrote: > For example, when linking with -lpthread you also need some flags so that > will be grokked by the compiler: > > # On OSF/1, the compiler needs the flag -pthread or -D_REENTRANT so that > # it groks . > > There are many more little complicati

Re: two more new warning/errors in coreutils/gnulib tests

Eric Blake wrote: > this particular use of system() is essential to the > test, and unlike the mingw system("rm") case, this one should assert > that the subprocess succeeded. OK, I've reverted your change and added an ASSERT: 2011-07-08 Bruno Haible sigprocmask tests: A better way t

Re: [PATCH 03/10] pthread_sigmask: new module

Another platform on which the pthread_sigmask unit test fails is IRIX 6.5: test-pthread_sigmask1.c:78: assertion failed FAIL: test-pthread_sigmask1 The cause: After pthread_sigmask returns, it needs a small usleep(1) before a pending signal is delivered. I'm committing this workaround: 2011-07-

Re: [PATCH 03/10] pthread_sigmask: new module

On 07/08/2011 05:02 PM, Bruno Haible wrote: > On Cygwin 1.7.5, the tests fail: > > test-pthread_sigmask1.c:56: assertion failed > FAIL: test-pthread_sigmask1.exe > test-pthread_sigmask2.c:63: assertion failed > FAIL: test-pthread_sigmask2.exe > > This is because it has the wrong return value conv

Re: two more new warning/errors in coreutils/gnulib tests

On 07/08/2011 04:54 PM, Bruno Haible wrote: > Hi Eric, > >> - system (command); >> + ignore_value (system (command)); > > Can you please remind me: Why not > > ASSERT (system (command) == 0); ? On mingw, using system("rm") does not always pass, and we had a series of complaints about usin

Re: [PATCH 03/10] pthread_sigmask: new module

On Cygwin 1.7.5, the tests fail: test-pthread_sigmask1.c:56: assertion failed FAIL: test-pthread_sigmask1.exe test-pthread_sigmask2.c:63: assertion failed FAIL: test-pthread_sigmask2.exe This is because it has the wrong return value convention: pthread_sigmask returns -1 and sets errno, contrary

Re: two more new warning/errors in coreutils/gnulib tests

Hi Eric, > -  system (command); > +  ignore_value (system (command)); Can you please remind me: Why not ASSERT (system (command) == 0); ? On Unix platforms, if system() returns nonzero, the user running the test better ought to know it, no? Bruno -- In memoriam Jean Moulin

Re: [PATCH] fts: introduce FTS_NOATIME

At least in the case of find it will be simple to expose this information in a useful way to the user: $ find --version find (GNU findutils) 4.4.2 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software:

Re: [PATCH 03/10] pthread_sigmask: new module

On FreeBSD 6.4, HP-UX 11, Solaris 9, the unit test fails like this: test-pthread_sigmask1.c:56: assertion failed FAIL: test-pthread_sigmask1 The reason is that pthread_sigmask does nothing - no error checking, not delaying signals - if it is the definition from libc (as opposed to the definition

Re: two more new warning/errors in coreutils/gnulib tests

On 07/08/2011 03:33 PM, Jim Meyering wrote: > In case someone else finds time to address these new warnings: > > test-sigprocmask.c: In function 'main': > test-sigprocmask.c:66:10: error: ignoring return value of 'system', declared > with attribute warn_unused_result [-Werror=unused-result] > cc1

two more new warning/errors in coreutils/gnulib tests

In case someone else finds time to address these new warnings: test-sigprocmask.c: In function 'main': test-sigprocmask.c:66:10: error: ignoring return value of 'system', declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make[8]: *** [te

[PATCH] test-getopt.h: avoid warning about an unused variable

Without this, coreutils (with latest gnulib) would fail to build when configured --enable-gcc-warnings: >From a406aaff57bc75a3410208e1abc7e86b0578c47c Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 8 Jul 2011 23:17:36 +0200 Subject: [PATCH] test-getopt.h: avoid warning about an unused var

Re: [PATCH 03/10] pthread_sigmask: new module

Hi Paul, > Thanks for that review, and for fixing all those problems. Oh, it's too early for the thanks: The unit tests still fail on five platforms, from FreeBSD to Solaris. > First, there's what appears > to be a clear typo in the gl_THREADLIB case: it is searching > for pthread_sigmask in a l

Re: [PATCH] fts: introduce FTS_NOATIME

Eric Blake wrote: > On 07/08/2011 12:03 PM, Paul Eggert wrote: >> On 07/08/11 10:27, Eric Blake wrote: >>> if O_NOATIME is 0, --noatime should be rejected as an outright >>> impossibility. >>> >>> if O_NOATIME is non-zero, --noatime should enable FTS_NOATIME, but only >>> as a best-effort (that is,

Re: [PATCH] fts: introduce FTS_NOATIME

On 07/08/2011 12:03 PM, Paul Eggert wrote: > On 07/08/11 10:27, Eric Blake wrote: >> if O_NOATIME is 0, --noatime should be rejected as an outright >> impossibility. >> >> if O_NOATIME is non-zero, --noatime should enable FTS_NOATIME, but only >> as a best-effort (that is, the option is silently ig

Re: [PATCH] fts: introduce FTS_NOATIME

On 07/08/11 10:27, Eric Blake wrote: > if O_NOATIME is 0, --noatime should be rejected as an outright > impossibility. > > if O_NOATIME is non-zero, --noatime should enable FTS_NOATIME, but only > as a best-effort (that is, the option is silently ignored where the > kernel is too old), If --noati

Re: [PATCH 03/10] pthread_sigmask: new module

Thanks for that review, and for fixing all those problems. I noticed a couple of issues. First, there's what appears to be a clear typo in the gl_THREADLIB case: it is searching for pthread_sigmask in a library, but it's using AC_COMPILE_IFELSE. Surely that should be AC_LINK_IFELSE. (I haven't te

Re: [PATCH] fts: introduce FTS_NOATIME

On 07/08/2011 10:55 AM, Jim Meyering wrote: > Eric Blake wrote: >> This gives clients the option to try a non-invasive traversal, >> where merely visiting a directory does not update its timestamp, >> where such is supported by the kernel. >> >> Note that whiteout support and O_NOATIME support are

Re: [PATCH 03/10] pthread_sigmask: new module

And here come the unit tests for pthread_sigmask. One test in single-threaded situation (not linked with -lpthread), one test in a multi-threaded program. I let you guess on how many platforms the tests fail... 2011-07-08 Bruno Haible Tests for module 'pthread_sigmask'. * mod

Re: [PATCH] fts: introduce FTS_NOATIME

Eric Blake wrote: > This gives clients the option to try a non-invasive traversal, > where merely visiting a directory does not update its timestamp, > where such is supported by the kernel. > > Note that whiteout support and O_NOATIME support are orthogonal: > there is no way to get O_NOATIME beha

Re: [PATCH] fts: introduce FTS_NOATIME

Eric Blake wrote: > On 07/07/2011 03:07 PM, Eric Blake wrote: >> On 07/07/2011 03:02 PM, Paul Eggert wrote: >>> On 07/07/11 10:41, Eric Blake wrote: This gives clients the option to try a non-invasive traversal, >>> >>> Thanks for doing that; a couple of minor comments: >>> -

Re: [PATCH] fts: introduce FTS_NOATIME

On 07/07/2011 03:07 PM, Eric Blake wrote: > On 07/07/2011 03:02 PM, Paul Eggert wrote: >> On 07/07/11 10:41, Eric Blake wrote: >>> This gives clients the option to try a non-invasive traversal, >> >> Thanks for doing that; a couple of minor comments: >> >>> -int fd = open (".", O_SEARCH

Re: thread: fix some gcc warnings

Eric Blake wrote: > > - (pthread_in_use () ? (void *) pthread_self () : NULL) > > + (pthread_in_use () ? pthread_self () : (pthread_t) NULL) > > This not portable. POSIX allows pthread_t to be a non-pointer type, so > you can't necessarily cast NULL to pthread_t. Yes, and the only platfo

Re: thread: fix some gcc warnings

On 07/08/2011 05:27 AM, Bruno Haible wrote: > The statement > gl_thread_t t = gl_thread_self (); > gives a gcc warning about assignment from a pointer to an integer. This fixes > it: > > > 2011-07-08 Bruno Haible > > thread: Avoid gcc warnings when using gl_thread_self(). > * li

thread: fix some gcc warnings

The statement gl_thread_t t = gl_thread_self (); gives a gcc warning about assignment from a pointer to an integer. This fixes it: 2011-07-08 Bruno Haible thread: Avoid gcc warnings when using gl_thread_self(). * lib/glthread/thread.h (gl_thread_self): Return a pthread_t, no