Re: [PATCH] maintainer-makefile: check for i18n setup

Eric Blake wrote: > * top/maint.mk (sc_bindtextdomain): Check for evidence that _() > will likely work. > > I recently debugged a situation in libvirt where a program had > not set up the i18n framework, therefore calls to _() were doing > nothing. If this rule had been in place, I would have quic

Re: Patch 3/3 for topic/libposix

On 12 Nov 2010, at 08:15, Bruce Korb wrote: > Hi Gary, et al., Hi Bruce, If you can configure your email program to quote patches inline without mangling them, it makes giving review feedback much easier (otherwise I have to save the patch, open it in an editor, copy the content of the patch, and

Re: Patch 2/3 for topic/libposix

Bruce Korb wrote: > This patch modifies lib/error.c so that should someone > call it without having set program_name, then a message > is printed and abort() called instead of seg faulting. A link error would be best, to detect this situation. If we cannot get a link error, an abort() is a small i

Re: Patch 1/3 for topic/libposix

Bruce Korb wrote: > First patch changes the failing printf tests so that: > 1. ... > 2. the wrapper scripts detect "I failed on the first >iteration" exit codes and causes the test to be >bypassed with "exit 77" exit codes. But that means that the test would be skipped in some circumstance

Re: Patch 2/3 for topic/libposix

On 11/11/2010 05:09 PM, Bruce Korb wrote: > This patch modifies lib/error.c so that should someone > call it without having set program_name, then a message > is printed and abort() called instead of seg faulting. It's not clear that this is a win. The current code, in glibc and in most other C l

Re: Patch 1/3 for topic/libposix

Hi Bruce, On 12 Nov 2010, at 08:07, Bruce Korb wrote: > First patch changes the failing printf tests so that: > 1. the executables are only fired up once > 2. the wrapper scripts detect "I failed on the first > iteration" exit codes and causes the test to be > bypassed with "exit 77" exit code

Re: test-fprintf-posix3.c:

Hi Bruce, > The test should emit more diagnostics when it fails. > The amount of trouble one has to go to to show you > this is extreme. It is hardly possible to write tests in such a way that 1) they are silent by default, 2) when there is a problem at any place, you have all necessary infor

Re: libposix build logs

Gary V. Vaughan wrote: >>ix86 RHEL 4 gcc 3.4.6 (test-fcntl-h-c++.cc compile failed: >> 133: symbol `mknod' already defined) >>x86_64 RHEL 4igcc 3.4.6 (test-fcntl-h-c++.cc compile failed: >> 124: s

Re: Patch 2/3 for topic/libposix

On 11/11/2010 06:09 PM, Bruce Korb wrote: > This patch modifies lib/error.c so that should someone > call it without having set program_name, then a message > is printed and abort() called instead of seg faulting. > Subject: [PATCH 2/3] give a sensible error message when error() is called > witho

Re: test for utimes, utimens test, glibc futimes()

On 11/11/2010 05:46 PM, Bruno Haible wrote: > Paul Eggert wrote: >> The glibc bug was introduced in 2003. I reported it back then; >> see . > > Neither Ulrich nor Jakub voiced his opinion about it, in that thread. So > the right actio

Patch 3/3 for topic/libposix

Hi Gary, et al., This patch removes modules/libposix and libposix/configure.ac, creating these files on the fly instead. Since the module file is now created by capturing the output of posix-modules, I also removed the validation from the libposix/bootstrap script. I also augmented it to follow

Patch 2/3 for topic/libposix

This patch modifies lib/error.c so that should someone call it without having set program_name, then a message is printed and abort() called instead of seg faulting. >From 70e49cdeba9becf444c6b6a6c6bd74e8fe6b80e4 Mon Sep 17 00:00:00 2001 From: Bruce Korb Date: Thu, 11 Nov 2010 08:46:00 -0800 Subje

Patch 1/3 for topic/libposix

First patch changes the failing printf tests so that: 1. the executables are only fired up once 2. the wrapper scripts detect "I failed on the first iteration" exit codes and causes the test to be bypassed with "exit 77" exit codes. >From f015bed9d6ad2fde5f0f86e941e8094e3eb14d37 Mon Sep 17 00

Re: libposix build logs

On 11/11/10 15:42, Bruno Haible wrote: > x86_64-redhat-linuxe3-libposix.log.bz2 contains a failure of > FAIL: test-fprintf-posix2.sh > FAIL: test-printf-posix2.sh > > But on the same build machine as you used (menori.il.thewrittenword.com), > with a testdir created with > $ ./gnulib-tool --c

Re: test for utimes, utimens test, glibc futimes()

Paul Eggert wrote: > The glibc bug was introduced in 2003. I reported it back then; > see . Neither Ulrich nor Jakub voiced his opinion about it, in that thread. So the right action would seem to report it again, this time through bug

[PATCH] maintainer-makefile: check for i18n setup

* top/maint.mk (sc_bindtextdomain): Check for evidence that _() will likely work. Signed-off-by: Eric Blake --- I recently debugged a situation in libvirt where a program had not set up the i18n framework, therefore calls to _() were doing nothing. If this rule had been in place, I would have q

Re: test for utimes, utimens test, glibc futimes()

On 11/11/2010 03:45 PM, Eric Blake wrote: > On 11/11/2010 04:32 PM, Bruno Haible wrote: >> - Is glibc's futimes() implementation correct? Is futimes() allowed to >> round >> up by as much as half a second? > > No. Eric is right. The POSIX spec for futimens, utimensat, and utimes says "The

Re: test for utimes, utimens test, glibc futimes()

On 11/11/2010 04:32 PM, Bruno Haible wrote: > Hi Eric, Paul, > > I'm seeing a test failure in test-utimens and test-futimens on a Linux/x86 > machine, and have a hard time understanding the reason. NFS seems to often be a culprit in exposing timing bugs :( (Have I ever mentioned how much NFS dis

Re: libposix build logs

Hi Gary, > I've regenerated and concatenated the build logs, config.log and verbose test > logs (on the machines that got that far) for the default compiler (whatever > configure discovered first) on most of the above machines. > > http://blog.azazil.net/buildlogs/ x86_64-redhat-linuxe3-libpos

test for utimes, utimens test, glibc futimes()

Hi Eric, Paul, I'm seeing a test failure in test-utimens and test-futimens on a Linux/x86 machine, and have a hard time understanding the reason. The test failure is occurring on a Linux 2.4.21 x86 machine (kaoru.il.thewrittenword.com) with gcc 3.2.3. test-utimens.h:101: assertion failed FAIL: t

Re: new module 'strerror_r-posix'

Daniel P. Berrange wrote: > > /* This lock protects the buffer returned by strerror(). We assume that > >no other uses of strerror() exist in the program. */ > > gl_lock_define_initialized(static, strerror_lock) > > It'd be good to have an impl that uses strerror_s() on Win32 > since I don

Re: m4/mknod.m4: minor portability fix

On 11/09/2010 09:38 AM, Christian Weisgerber wrote: > I noticed this in GNU tar 1.25 when FreeBSD's test(1) complained: > > Use "=" operator for test(1), rather than non-standard "==". > > > --- m4/mknod.m4.orig Tue Nov 9 17:35:22 2010 > +++ m4/mknod.m4 Tue Nov 9 17:35:32 2010 > @@ -30,

Re: Typo in unlink.m4

On 11/11/2010 05:27 AM, Reuben Thomas wrote: > /home/rrt/repo/gnulib/m4/unlink.m4 > 35: AC_CACHE_CHECK([whether unlink of a parent directory fails is it should], > > Presumably "is it should" should be "if it should" or "as it should"? 'as it should'. I was about to pushed the fix in your name,

Re: Typo in unlink.m4

On 11/11/2010 04:27 AM, Reuben Thomas wrote: > 35: AC_CACHE_CHECK([whether unlink of a parent directory fails is it should], > > Presumably "is it should" should be "if it should" or "as it should"? "as it should" sounds good. I pushed that. Thanks for reporting it.

Re: test-fprintf-posix3.c:

On 11/11/10 01:20, Bruno Haible wrote: > Bruce Korb wrote: >> I finally ... used GDB. > > Good. The test should emit more diagnostics when it fails. The amount of trouble one has to go to to show you this is extreme. >> 79void *memory = malloc (MAX_ALLOC_TOTAL); >> (gdb) >> 80

Re: new module 'strerror_r-posix'

On Thu, Nov 11, 2010 at 01:26:37PM +0100, Bruno Haible wrote: > > Here's a draft proposal: A new module 'strerror_r-posix'. I wouldn't want > > to call it 'strerror_r' because that would be misunderstandable. > > During testing, more portability problems appeared. Here's what I'm > committing: >

Typo in unlink.m4

/home/rrt/repo/gnulib/m4/unlink.m4 35: AC_CACHE_CHECK([whether unlink of a parent directory fails is it should], Presumably "is it should" should be "if it should" or "as it should"? -- http://rrt.sc3d.org

Re: new module 'strerror_r-posix'

> Here's a draft proposal: A new module 'strerror_r-posix'. I wouldn't want > to call it 'strerror_r' because that would be misunderstandable. During testing, more portability problems appeared. Here's what I'm committing: 2010-11-11 Bruno Haible New module 'strerror_r-posix'.

Re: new module 'strerror_r-posix' (was: Re: strerror thread-safety?)

Adam Stokes wrote: > > License: > > LGPL > > May I ask that the license be LGPLv2+? I guess that's again for libvirt, which we have already discussed. So, yes. Bruno

Re: [PATCH] pmccabe2html: bug fixes: don't skip last input line; quote filename in shell command

torsten.sch...@leica-microsystems.com writes: > * build-aux/pmccabe2html: Fixed a off-by-one error, so last input line is > also considered for output. Quoted function name in shell command, so > temporary files for functions like MyClass::operator() are removed > correctly without errors. Tha

Re: test-fprintf-posix3.c:

Bruce Korb wrote: > I finally ... used GDB. Good. > RLIMIT_DATA and RLIMIT_AS appear to be set to 10,000,000. > An attempt to malloc 10 million (MAX_ALLOC_TOTAL) fails > and the two failing tests exit with status "1". When you look at test-fprintf-posix3.sh: The first test is expected to fail wi