GNU bug report logs -
#7325
new test failure due to non-portability of printf formats like %05.3s
Previous Next
Reported by: Jim Meyering <jim <at> meyering.net>
Date: Wed, 3 Nov 2010 18:56:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 06 Nov 2010 14:20:50 +0000
with message-id <4CD56442.1000404 <at> draigBrady.com>
and subject line Re: bug#7325: new test failure due to non-portability of printf formats like %05.3s
has caused the GNU bug report #7325,
regarding new test failure due to non-portability of printf formats like %05.3s
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
7325: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7325
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
At least on Solaris 10, the new stat-nanoseconds test fails,
due to non-portability of snprintf vs a format like %010.3s:
FAIL: misc/stat-nanoseconds
...
+ touch -d '2010-10-21 18:43:33.023456789' k
...
++ stat -c %05.3:X k
+ test 00023 = ' 023'
+ fail=1
You can demonstrate it with bash's built-in printf, too:
solaris$ bash -c "printf '%010.3s\n' 23"
0000000023
glibc$ bash -c "printf '%010.3s\n' 23"
23
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'll sleep on it.
Other opinions welcome, as usual.
[Message part 3 (message/rfc822, inline)]
On 06/11/10 02:54, Paul Eggert wrote:
> On 11/04/2010 11:34 PM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> I still slightly prefer just using %.X as
>>> it's backwards compat with older coreutils (excluding 8.6).
>>
>> So do I.
>
> I built that and tried it out, and found another problem that has been
> annoying me for years in other programs: 'stat' prints out unnecessary
> trailing zeros for time stamps, when the file system resolution is
> coarser than nanosecond resolution. So I figured I'd fix that too,
> for 'stat' (other programs can be fixed later). With this fix, %.X
> outputs the time stamp but omits trailing zeros if it can infer that
> the file system would always put zeros there. If you want a specific
> number of zeros, you can use something like %.3X or %.9X (or %.100X :-).
Interesting. So it's variable precision by default
$ touch -d '1970-01-01 18:43:33.5000000000' 2; ~/git/t/coreutils/src/stat -c "%.W %.X %.Y %.Z" 2
0.000000000 63813.500000000 63813.500000000 1289052572.699980883
$ touch -d '1970-01-01 18:43:33.5000000000' 2; ~/git/t/coreutils/src/stat -c "%.W %.X %.Y %.Z" 2
0.00000000 63813.50000000 63813.50000000 1289052573.53698077
I like it.
BTW you dropped a blank line at the end of the NEWS section.
cheers,
Pádraig.
p.s. I'm marking this bug as done
This bug report was last modified 14 years and 191 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.