Re: gengetopt, anyone?

I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. Why aren't I using it? -- http://rrt.sc3

[PATCH] maint.mk: adjust a release-related rule not to require use of gzip

In preparing to stop building gzip-compressed tarballs in a few projects I maintain, this change comes in handy: >From 244794a7887f13d9cdb91fed96932cc479905b96 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 1 Oct 2011 17:33:42 +0200 Subject: [PATCH] maint.mk: adjust a release-related rule

[PATCH] test-linkat: don't leave behind a temporary file

FYI, >From 24fae8f857a1ab285dc936e697f1e10138e9 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 1 Oct 2011 15:06:43 +0200 Subject: [PATCH] test-linkat: don't leave behind a temporary file * tests/test-linkat.c (main): Don't forget to remove a temporary file. Otherwise, coreutils' "mak

Re: float, math: Fix 'int' to 'long double' conversion on Linux/SPARC64

Bruno Haible wrote: > Jim Meyering wrote: >> I've taken the liberty of adding the above file. > > Oops, I forgot a "git add" command. Thanks for the fix. If you always write ChangeLog entries before committing, using "vc-dwim --commit" to perform the commit would prevent precisely this problem (am

Re: float, math: Fix 'int' to 'long double' conversion on Linux/SPARC64

Jim Meyering wrote: > I've taken the liberty of adding the above file. Oops, I forgot a "git add" command. Thanks for the fix. Bruno -- In memoriam Max Ehrlich

Re: float, math: Fix 'int' to 'long double' conversion on Linux/SPARC64

Bruno Haible wrote: > It started as a test failure on Linux/SPARC64: > > test-logl.c:42: assertion failed > FAIL: test-logl > > I tried to fix it by activating the gnulib replacement code for logl(). But > the bug persisted. > > Debugging it in detail, it turned out to be a bug in the 'int' to

isinf on OpenBSD

On OpenBSD 4.9/x86 I get this test failure: test-isinf.c:214: assertion failed FAIL: test-isinf Apparently isinf considers pseudo-infinities to be infinities. This patch fixes it. 2011-10-01 Bruno Haible isinf: Fix for OpenBSD/x86. * m4/isinf.m4 (gl_ISINFL_WORKS): Also t

isfinite: fix syntax error

Another bug in the configure test: 2011-10-01 Bruno Haible isfinite: Fix syntax error in configure test. * m4/isfinite.m4 (gl_ISFINITEL_WORKS): Fix syntax error. --- m4/isfinite.m4.orig Sat Oct 1 11:55:35 2011 +++ m4/isfinite.m4 Sat Oct 1 11:55:20 2011 @@ -148,7 +148,7

isfinite: fix cross-compilation

An obvious copy&paste bug: 2011-10-01 Bruno Haible isfinite: Fix typo. * m4/isfinite.m4 (gl_ISFINITEL_WORKS): When cross-compiling, set gl_cv_func_isfinitel_works, not gl_cv_func_isnanl_works. --- m4/isfinite.m4.orig Sat Oct 1 11:48:05 2011 +++ m4/isfinite.m4 Sa

Re: mkfifoat tests on mingw

I've committed this patch now: > 2011-09-21 Bruno Haible > > mkfifoat tests: Fix a test failure on mingw. > * tests/test-mkfifoat.c (main): Allow mkfifoat or test_mknodat to fail > with error ENOSYS. > > --- tests/test-mkfifoat.c.origThu Sep 22 02:12:07 2011 >

test-utimensat failure on Linux/hppa

Hi Eric, On a Linux/hppa machine I'm seeing this test failure: test-utimens.h:73: assertion failed FAIL: test-utimensat and then when this is fixed: test-utimens.h:79: assertion failed But POSIX:2008 really wants an EINVAL failure for invalid tv_nsec values[1]. On this platform, the wra