Re: [PATCH] fix build warning in fnmatch_loop.c

Btw, excuse me for the duplicate mail. It's a bit odd, but I don't receive any mail from the list (my server doesn't register attempts from mailman), even though I'm subscribed (if I try to re-subscribe, I do receive a notification). Perhaps someone could investigate this? -- Robert Millan

version-etc tweak

Back in January, we had a discussion about formatting of --help output. The result was that coreutils changed to a new style. It has now been several months and several releases, with no complaints about the new style. Also, autoconf 2.64 has been released in the meantime, with support for a

Re: 4 test failures on freebsd8-rc2

Eric Blake wrote: > Jim Meyering meyering.net> writes: >> If I'd known this was coming so quickly, I would have delayed >> making the coreutils snapshot. >> >> Let me know when you're done: maybe I'll make one more >> before the release. > > At least a couple more to go. I've confirmed that on Fr

Re: [PATCH] fix build warning in fnmatch_loop.c

> I'm not a fan of unnecessary casts. Can't we instead write this as: > > : p - startp + 1U; > > to still show that we intend for unsigned math, but without a cast? The warning persists. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you

Re: 4 test failures on freebsd8-rc2

Jim Meyering meyering.net> writes: > If I'd known this was coming so quickly, I would have delayed > making the coreutils snapshot. > > Let me know when you're done: maybe I'll make one more > before the release. At least a couple more to go. I've confirmed that on FreeBSD: touch f ln -s f l

Re: [PATCH] Fix $m4dirs count

> This is wrong, since 'echo -n' is not portable. It should use printf > instead, > or find some other portable way to count $m4dirs. Hi, In that case, please use printf. It should work too. (I assume it's not necessary to send a new patch, let me know if you'd like me to) -- Robert Millan

[PATCH] fix build warning in fnmatch_loop.c

Fixes a build warning in fnmatch_loop.c. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." gnulib/fnmatch_loop

Re: [PATCH] fix build warning in fnmatch_loop.c

Robert Millan aybabtu.com> writes: > Fixes a build warning in fnmatch_loop.c. > > > -: p - startp + 1); \ > +: (unsigned) (p - startp) + 1); \ I'm not a fan of unnecessary casts. Can't we instead write this as: : p - startp + 1U; to still show that we intend for unsigned

[PATCH] fix build warning in fnmatch_loop.c

Fixes a build warning in fnmatch_loop.c. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." gnulib/fnmatch_loop

Re: [PATCH] Fix $m4dirs count

Robert Millan aybabtu.com> writes: > $m4dirs is incorrectly counting. In my particular case > (correct value: 0, detected value: 1), this resulted in gnulib-tool > silently exitting with no visible error (and no job done). > > - m4dirs_count=`echo "$m4dirs" | wc -l` > + m4dirs

[PATCH] Fix $m4dirs count

$m4dirs is incorrectly counting. In my particular case (correct value: 0, detected value: 1), this resulted in gnulib-tool silently exitting with no visible error (and no job done). -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may acc

Re: 4 test failures on freebsd8-rc2

Eric Blake wrote: > According to Eric Blake on 11/2/2009 8:37 PM: >>> test-rename.h:141: assertion failed >> >> Looks like a case of BSD returning a non-standard errno, but where it is >> easier to teach the test one more errno to allow than to wrap the BSD bug. >> Now, if only I knew which errno

Re: 4 test failures on freebsd8-rc2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 11/2/2009 8:37 PM: >> test-rename.h:141: assertion failed > > Looks like a case of BSD returning a non-standard errno, but where it is > easier to teach the test one more errno to allow than to wrap the BSD bug. > Now, if o

Re: improving manywarnings

Eric Blake writes: > I'm considering using manywarnings in m4, and noticed that newer gcc > supports even more warnings. I noticed several warnings supported by gcc > 4.3.4 --help=warnings that were not listed already; see the patch below. > However, looking at it closer, it is obvious that some

Re: solaris 9: undefined symbol rpl_open

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Thomas Guyot-Sionnest on 11/8/2009 10:17 PM: >> Maybe you have some stale state, possibly from an outdated .m4 macro being >> picked up, or a config.cache that is not remembering the right values. I've >> also seen cases where 'rm gl/fc

Re: [PATCH] fprintftime: avoid a warning about ignored fwrite return value

James Youngman wrote: > On Wed, Oct 28, 2009 at 9:34 AM, Jim Meyering wrote: >> Here's hoping that POSIX (or ISO C) will eventually fix fputc/fwrite/etc. >> so that we don't have to add caveats like what I wrote in the comment below. >> >> As far as I know, date, du --time and uptime are the only

Re: [PATCH] fprintftime: avoid a warning about ignored fwrite return value

On Wed, Oct 28, 2009 at 9:34 AM, Jim Meyering wrote: > Here's hoping that POSIX (or ISO C) will eventually fix fputc/fwrite/etc. > so that we don't have to add caveats like what I wrote in the comment below. > > As far as I know, date, du --time and uptime are the only clients that > use fprintfti