Paolo Bonzini wrote:
> > I'll think I'll merge the test for EXP_LIBM, LOG_LIBM etc. into a single
> > one - to save configure script execution time, as you say -.
>
> That's fair enough, thanks.
Implemented as follows:
2010-01-31 Bruno Haible
Perform the same test for many function
Hi Martin,
> sc_po_check:
>
>
> This one complains about files like lib/getopt.c not being listed as
> requiring translations. OK, it has a point there. Still, of the three
> possible solutions which come to my mind, none feels exactly right:
>
> 1. Add files, and require every tran
> 2010-01-31 Bruno Haible
>
> Work around getline() bug on FreeBSD 8.0.
> * m4/getline.m4 (gl_FUNC_GETLINE): Also test result for a NULL buffer
> and a non-zero size.
> * tests/test-getline.c (main): Likewise.
> * doc/posix-functions/getline.texi: Mention the FreeB
Eric Blake wrote:
> FreeBSD is buggy. Rewording the POSIX requirement slightly: if lineptr is
> NULL, then it is irrelevant that linecapp is non-zero.
I agree.
> Gnulib needs to work around this portability flaw, and guarantee a working
> getline implementation even on fBSD, at which point, your
Hi Bruno,
thanks for the additional information.
* Bruno Haible wrote on Sun, Jan 31, 2010 at 12:32:06PM CET:
> Ralf Wildenhues asked:
> > What are the "other cases" you mention, where no process was terminated
> > by the signal, but the signal delivered somewhere nonethess?
>
> When I run
>
* Dmitry V. Levin wrote on Sun, Jan 31, 2010 at 01:04:01PM CET:
> On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote:
> > Can you please explain whose fault this is? Is that a kernel issue, a
> > shell issue, or expected behavior given a POSIX system?
>
> It is expected behaviour.
>
On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote:
> * Dmitry V. Levin wrote on Sat, Jan 30, 2010 at 08:12:01PM CET:
> > There is a comment about shell signal handlers in gnulib-tool saying that
> > "The value of $? is 128 + signal number and is set before the
> > trap-registered comm
Jim Meyering wrote:
> Imagine that the first 10 tests pass, then each of the remaining ones is
> killed via e.g., SIGHUP. ...
> a naive search for "FAIL:" in the build output would find nothing.
Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he
should be encouraged to invest
Ralf Wildenhues asked:
> What system and shell (version?) were your tests done on?
I could reproduce Dmitry's tests, with 'sleep 1' instead of 'sleep 0.01'.
$ for i in `seq 0 9`; do sh -c 'trap "exit \$?" TERM; while /bin/true; do
/bin/false; done' & pid=$! && sleep 1 && kill -TERM -$pid && wait
