bug#7325: new test failure due to non-portability of printf formats like %05.3s
Pádraig Brady wrote: ... >> That's simply an issue of whether the value is considered to be signed >> or unsigned, and can be fixed by the patch at the end of this message. >> >> However, let me take a step back a minute. Do users really want all >> this functionality? Personally, what I'd like to see is a single >> format like this: >> >>%.3X >> >> that prints out the entire seconds since the Epoch, truncated >> to millseconds. That's simpler than what we require now: >> >>%X.%.3:X >> >> The changelogs suggest that we used to do things the simpler way, >> but changed on Oct. 21. I don't recall this being discussed: I >> assume it was due to floating point rounding issues. Still, I'd >> prefer the simpler notation, and we should be able to implement it >> without floating point. Would that be OK? The idea would be >> to support ".PRECISION" in the formats for W, X, Y, and Z, and >> to drop support for ':W' and the like. > > I think you're echoing my suggestion here: > http://comments.gmane.org/gmane.comp.gnu.coreutils.general/369 Oh! Indeed. Sorry I didn't see that part of the thread. > Given the counter arguments there it was decided to > split to X and :X etc. > > I still slightly prefer just using %.X as > it's backwards compat with older coreutils (excluding 8.6). So do I.
bug#7331: Date command bug
Raymond Pete wrote: > I believe I have come across a small bug in the date command when daylight > savings time is in the process of being run. Thank you for the report. But what you are describing looks like an incorrect expectation of behavior to me. > date --set "7 NOV 2010" > -->Sun Nov 7 00:00:01 EDT 2010 You don't need to actually set the date and mess with the system clock. Just use --date and have date interpret the date string. It would make for a more reliable example. > date --date="+1 day" > -->Sun Nov 7 23:00:40 EST 2010 I assume that EDT and EST here are US/Eastern DST and US/Eastern standard time? Better to use 'date -R' to produce numeric values that are not ambiguous. $ TZ=US/Eastern date -R -d "Sun, 07 Nov 2010 00:00:01 -0400 +1 day" Sun, 07 Nov 2010 23:00:01 -0500 > It would appear in Eastern time zone case there is a small 2 hour window of > error here whereby the date command has set the zone before it is actually > supposed to be set. I have seen this with all time zone shifts. Noticed > first last weekend when BST went to GMT. I don't understand. "7 NOV 2010" doesn't have a time associated with it and so the zero hour (midnight) is used. $ zdump -v US/Eastern | grep 2010 US/Eastern Sun Nov 7 05:59:59 2010 UTC = Sun Nov 7 01:59:59 2010 EDT isdst=1 gmtoff=-14400 US/Eastern Sun Nov 7 06:00:00 2010 UTC = Sun Nov 7 01:00:00 2010 EST isdst=0 gmtoff=-18000 November 7th at midnight is still within daylight savings time. Then you say "+1 day" which adds 24 hours to the current clock time and produces a time that is 24 hours later but *after* US/Eastern has changed to standard time. "Spring forward and Fall back." If you were expecting it to be midnight on the next day then you have forgotten that there is an extra hour inserted in the Fall when the clocks are turned back one hour. > Could be a known bug.. if so, sorry to trouble you guys. I see no bug here. Please explain if I missed something. See also this reference for more information: http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e Bob
bug#7331: Date command bug
Hi, I believe I have come across a small bug in the date command when daylight savings time is in the process of being run. Example: date --set "7 NOV 2010" -->Sun Nov 7 00:00:01 EDT 2010 date --date="+1 day" -->Sun Nov 7 23:00:40 EST 2010 It would appear in Eastern time zone case there is a small 2 hour window of error here whereby the date command has set the zone before it is actually supposed to be set. I have seen this with all time zone shifts. Noticed first last weekend when BST went to GMT. Could be a known bug.. if so, sorry to trouble you guys. Best Regards, Ray
bug#7325: new test failure due to non-portability of printf formats like %05.3s
On 04/11/10 20:10, Paul Eggert wrote: > On 11/04/10 00:56, Jim Meyering wrote: > >> However, what about Eric's example? >> >> $ src/stat-p -c '_%-0 010.4:X_' k # yours >> _234 _ >> $ src/stat-j -c '_%-0 010.4:X_' k # mine >> _0234 _ > > That's simply an issue of whether the value is considered to be signed > or unsigned, and can be fixed by the patch at the end of this message. > > However, let me take a step back a minute. Do users really want all > this functionality? Personally, what I'd like to see is a single > format like this: > >%.3X > > that prints out the entire seconds since the Epoch, truncated > to millseconds. That's simpler than what we require now: > >%X.%.3:X > > The changelogs suggest that we used to do things the simpler way, > but changed on Oct. 21. I don't recall this being discussed: I > assume it was due to floating point rounding issues. Still, I'd > prefer the simpler notation, and we should be able to implement it > without floating point. Would that be OK? The idea would be > to support ".PRECISION" in the formats for W, X, Y, and Z, and > to drop support for ':W' and the like. I think you're echoing my suggestion here: http://comments.gmane.org/gmane.comp.gnu.coreutils.general/369 Given the counter arguments there it was decided to split to X and :X etc. I still slightly prefer just using %.X as it's backwards compat with older coreutils (excluding 8.6). cheers, Pádraig.
bug#7325: new test failure due to non-portability of printf formats like %05.3s
Paul Eggert wrote: > On 11/04/10 00:56, Jim Meyering wrote: > >> However, what about Eric's example? >> >> $ src/stat-p -c '_%-0 010.4:X_' k # yours >> _234 _ >> $ src/stat-j -c '_%-0 010.4:X_' k # mine >> _0234 _ > > That's simply an issue of whether the value is considered to be signed > or unsigned, and can be fixed by the patch at the end of this message. > > However, let me take a step back a minute. Do users really want all > this functionality? Personally, what I'd like to see is a single > format like this: > >%.3X > > that prints out the entire seconds since the Epoch, truncated > to millseconds. That's simpler than what we require now: > >%X.%.3:X > > The changelogs suggest that we used to do things the simpler way, > but changed on Oct. 21. I don't recall this being discussed: I It was due to portability concerns, since with coreutils-8.6, %X, %Y, etc. expanded to floating point values, and that broke backwards compatibility: http://thread.gmane.org/gmane.comp.gnu.coreutils.general/161/focus=366 However, enabling floating point output only when there is a ".PREC" part of the format sounds like a fine compromise. Sure, old scripts that used %.3X (expecting no ".") would break, but I doubt any such uses exist, since that notation did nothing useful. A patch would be most welcome. > assume it was due to floating point rounding issues. Still, I'd > prefer the simpler notation, and we should be able to implement it > without floating point. Would that be OK? The idea would be > to support ".PRECISION" in the formats for W, X, Y, and Z, and > to drop support for ':W' and the like.
bug#7325: new test failure due to non-portability of printf formats like %05.3s
On 11/04/10 00:56, Jim Meyering wrote:
> However, what about Eric's example?
>
> $ src/stat-p -c '_%-0 010.4:X_' k # yours
> _234 _
> $ src/stat-j -c '_%-0 010.4:X_' k # mine
> _0234 _
That's simply an issue of whether the value is considered to be signed
or unsigned, and can be fixed by the patch at the end of this message.
However, let me take a step back a minute. Do users really want all
this functionality? Personally, what I'd like to see is a single
format like this:
%.3X
that prints out the entire seconds since the Epoch, truncated
to millseconds. That's simpler than what we require now:
%X.%.3:X
The changelogs suggest that we used to do things the simpler way,
but changed on Oct. 21. I don't recall this being discussed: I
assume it was due to floating point rounding issues. Still, I'd
prefer the simpler notation, and we should be able to implement it
without floating point. Would that be OK? The idea would be
to support ".PRECISION" in the formats for W, X, Y, and Z, and
to drop support for ':W' and the like.
>From 1dc473cc61099d5a1bf6bc26358bafd81cd670bd Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 4 Nov 2010 12:56:17 -0700
Subject: [PATCH] * src/stat.c (out_ns): Treat the ns value as being signed.
---
src/stat.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/stat.c b/src/stat.c
index c1def13..dd352a4 100644
--- a/src/stat.c
+++ b/src/stat.c
@@ -481,7 +481,7 @@ out_ns (char *pformat, size_t prefix_len, struct timespec
arg)
in the modifier, then then treat the modifier as operating
on the default representation, i.e., a zero padded number
of width 9. */
- unsigned long int ns = arg.tv_nsec;
+ long int ns = arg.tv_nsec;
char *dot = memchr (pformat, '.', prefix_len);
if (dot)
@@ -504,12 +504,12 @@ out_ns (char *pformat, size_t prefix_len, struct timespec
arg)
return;
for (; precision < 9; precision++)
ns /= 10;
- strcpy (dot, "lu");
+ strcpy (dot, "ld");
}
else
{
- char const *fmt = (prefix_len == 1) ? "09lu" : "lu";
- /* Note that pformat is big enough, as %:X -> %09lu
+ char const *fmt = (prefix_len == 1) ? "09ld" : "ld";
+ /* Note that pformat is big enough, as %:X -> %09ld
and two extra bytes are already allocated. */
strcpy (pformat + prefix_len, fmt);
}
--
1.7.2
bug#7324: coreutils on Solaris 10
On 11/04/2010 09:15 AM, Jim Meyering wrote: >> Yes, a self-built coreutils on that machine can once again 'touch'. I'm >> pushing this. Does this also deserve a NEWS entry? I'm not quite sure >> how it would be worded; maybe: >> >> cp, mv, and touch no longer crash when setting file times on Solaris >> 10 [latent bug since at least coreutils-5.97, exposed by recent >> Solaris patch] > > Thanks for handling that. > I think that anything that evokes a crash will always deserve a NEWS entry. > > It's ok to say we're not sure. > There's a limit to how much time we can spend on this sort of archeology. > > [a latent utimens.m4 bug introduced in 8.1 was triggered only by a > recent Solaris 10 update; there may have been another going back as > far as 5.97] Thanks for the wording suggestions. > > If you can easily find an ID for the offending Solaris 10 patch > it'd be nice to mention it here or in the commit log. > Looking at this page for an idea of Solaris patch ids, http://blogs.sun.com/patch/entry/solaris_10_kernel_patchid_progression and the uname information of the machine I see the problem on: SunOS xxx 5.10 Generic_144488-01 sun4u sparc SUNW,Sun-Blade-1000 Solaris I'm going ahead with this NEWS entry: cp, install, mv, and touch no longer crash when setting file times on Solaris 10 Update 9 [Solaris PatchID 144488 and newer expose a latent bug introduced in coreutils 8.1, and possibly a second latent bug going at least as far back as coreutils 5.97] -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#7324: coreutils on Solaris 10
Eric Blake wrote: > On 11/03/2010 12:33 PM, Eric Blake wrote: >> On 11/03/2010 11:39 AM, Eric Blake wrote: >>> * m4/utimens.m4 (gl_UTIMENS): Include correct headers. >>> >> >> I've confirmed that with this fix, the latest gnulib now passes all >> time-setting tests except those related to symlink times. I'm now in >> the process of testing coreutils on the same machine to see if the fixed >> gnulib test makes touch start working again. > > Yes, a self-built coreutils on that machine can once again 'touch'. I'm > pushing this. Does this also deserve a NEWS entry? I'm not quite sure > how it would be worded; maybe: > > cp, mv, and touch no longer crash when setting file times on Solaris > 10 [latent bug since at least coreutils-5.97, exposed by recent > Solaris patch] Thanks for handling that. I think that anything that evokes a crash will always deserve a NEWS entry. > And I don't know whether to state that the bug was introduced in 8.1 > (the point at where the gnulib utimens.m4 file was broken) or earlier > (since we have a definitive report of 5.97 not working, but not > intermediate versions; also recalling that utimens was moved from > coreutils over to gnulib between 5.97 and 8.1 and has seen quite a lot > of churn over the years). It's ok to say we're not sure. There's a limit to how much time we can spend on this sort of archeology. [a latent utimens.m4 bug introduced in 8.1 was triggered only by a recent Solaris 10 update; there may have been another going back as far as 5.97] If you can easily find an ID for the offending Solaris 10 patch it'd be nice to mention it here or in the commit log.
bug#7324: coreutils on Solaris 10
On 11/03/2010 12:33 PM, Eric Blake wrote: > On 11/03/2010 11:39 AM, Eric Blake wrote: >> * m4/utimens.m4 (gl_UTIMENS): Include correct headers. >> > > I've confirmed that with this fix, the latest gnulib now passes all > time-setting tests except those related to symlink times. I'm now in > the process of testing coreutils on the same machine to see if the fixed > gnulib test makes touch start working again. Yes, a self-built coreutils on that machine can once again 'touch'. I'm pushing this. Does this also deserve a NEWS entry? I'm not quite sure how it would be worded; maybe: cp, mv, and touch no longer crash when setting file times on Solaris 10 [latent bug since at least coreutils-5.97, exposed by recent Solaris patch] And I don't know whether to state that the bug was introduced in 8.1 (the point at where the gnulib utimens.m4 file was broken) or earlier (since we have a definitive report of 5.97 not working, but not intermediate versions; also recalling that utimens was moved from coreutils over to gnulib between 5.97 and 8.1 and has seen quite a lot of churn over the years). From 7b4e77352d7e7fc1ba37c3437d9a68f55fbdb668 Mon Sep 17 00:00:00 2001 From: Eric Blake Date: Thu, 4 Nov 2010 08:16:04 -0600 Subject: [PATCH] cp, mv, touch: fix file time manipulation on Solaris 10 * gnulib: Update to latest, for futimens fix. * .gitignore: Ignore another recent gnulib-generated file. --- .gitignore |1 + gnulib |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/.gitignore b/.gitignore index 1b8cae2..cd73b9a 100644 --- a/.gitignore +++ b/.gitignore @@ -51,6 +51,7 @@ /lib/progname.c /lib/progname.h /lib/selinux +/lib/stamp-h1 /lib/unistr /lib/uniwidth /lib/unused-parameter.h diff --git a/gnulib b/gnulib index 87f692b..37b74cd 16 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject commit 87f692bf1126a16c40212bcdb5324625939cef2a +Subproject commit 37b74cd909f60076a096ab8ac2635bc77755153f -- 1.7.3.2 * gnulib 87f692b...37b74cd (2): > tests: fix compiler warnings > utimens: fix broken m4 test -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#7325: new test failure due to non-portability of printf formats like %05.3s
Paul Eggert wrote: > The test-case part of that looks OK, but the change to stat.c > can be simplified. Also, there's a similar problem with a format > like %020X, which should be fixed too. > > While we're on the subject, there are other ways that stat invokers > can exercise undefined behavior (in the C sense) by passing > weird formats in. This really should get fixed at some point. > The patch proposed below addresses just the immediate issue. > >>From a24a9ce8f3711670a6413c60b5e9ebd3e51a4e06 Mon Sep 17 00:00:00 2001 > From: Paul Eggert > Date: Wed, 3 Nov 2010 15:49:50 -0700 > Subject: [PATCH] stat: handle leading '0' when formatting secs and ns > > * src/stat.c (epoch_sec): Remove. All callers changed to use > out_epoch_sec instead. > (out_ns): Use numeric format, not string format, to output > the nanoseconds count; this avoids unportable use of (e.g.) > %05s in a printf format. > (out_epoch_sec): New function. This also uses a numeric format, > instead of a string format, to output a number. However, what about Eric's example? $ src/stat-p -c '_%-0 010.4:X_' k # yours _234 _ $ src/stat-j -c '_%-0 010.4:X_' k # mine _0234 _ and printf (note how it includes the leading space): $ env printf '_%-0 010.4d_\n' 234 _ 0234 _
bug#7325: new test failure due to non-portability of printf formats like %05.3s
Paul Eggert wrote: > The test-case part of that looks OK, but the change to stat.c > can be simplified. Also, there's a similar problem with a format > like %020X, which should be fixed too. > > While we're on the subject, there are other ways that stat invokers > can exercise undefined behavior (in the C sense) by passing > weird formats in. This really should get fixed at some point. > The patch proposed below addresses just the immediate issue. > >>From a24a9ce8f3711670a6413c60b5e9ebd3e51a4e06 Mon Sep 17 00:00:00 2001 > From: Paul Eggert > Date: Wed, 3 Nov 2010 15:49:50 -0700 > Subject: [PATCH] stat: handle leading '0' when formatting secs and ns > > * src/stat.c (epoch_sec): Remove. All callers changed to use > out_epoch_sec instead. > (out_ns): Use numeric format, not string format, to output > the nanoseconds count; this avoids unportable use of (e.g.) > %05s in a printf format. > (out_epoch_sec): New function. This also uses a numeric format, > instead of a string format, to output a number. Thanks! I like it. FYI, I need slightly different tests for that, so am amending with these: diff --git a/tests/misc/stat-nanoseconds b/tests/misc/stat-nanoseconds index 314f43e..44862eb 100755 --- a/tests/misc/stat-nanoseconds +++ b/tests/misc/stat-nanoseconds @@ -26,11 +26,11 @@ ls --full-time | grep 18:43:33.023456789 \ test "$(stat -c %:X k)" = 023456789 || fail=1 test "$(stat -c %3:X k)" = 23456789 || fail=1 -test "$(stat -c %3.3:X k)" = 023|| fail=1 -test "$(stat -c%.3:X k)" = 023|| fail=1 +test "$(stat -c %3.3:X k)" = ' 23' || fail=1 +test "$(stat -c%.3:X k)" = 23 || fail=1 test "$(stat -c %03.3:X k)" = 023|| fail=1 -test "$(stat -c %-5.3:X k)" = '023 '|| fail=1 -test "$(stat -c %05.3:X k)" = ' 023'|| fail=1 -test "$(stat -c %010.3:X k)" = ' 023' || fail=1 +test "$(stat -c %-5.3:X k)" = '23 '|| fail=1 +test "$(stat -c %05.3:X k)" = 00023 || fail=1 +test "$(stat -c %010.3:X k)" = 23 || fail=1 Exit $fail
bug#7325: new test failure due to non-portability of printf formats like %05.3s
Pádraig Brady wrote: > On 03/11/10 19:27, Eric Blake wrote: >> On 11/03/2010 12:59 PM, Jim Meyering wrote: >>> Note that coreutils' printf does not accept the '0' modifier in a %s format. >>> >>> $ env printf '%05.3s\n' 23 >>> printf: %05.3s: invalid conversion specification >>> >>> That's because POSIX says the "0" modifier applies only to the >>> d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversion specifiers. >>> >>> One solution is to trim off the "0". >>> It's probably a good idea regardless, in case some implementation rejects >>> it. >>> >>> On the other hand, I find the zero-padding you currently get >>> with stat on solaris to be slightly more intuitive. >> >> I agree that %05.3:X resulting in 00023 would be ideal. > > I disagree because I can't see how that's useful. > The above is for 023xx nanoseconds. > So what is 23 in that context? The reason I prefer the above is that (regardless of semantics) it is consistent with what one would expect of a numeric conversion specifier. That means no surprises for the user who knows about printf and no need to document anything different about how stat's %[WXYZ] specifiers work.
