Subject: bug#7325: closed (Re: bug#7325: new test failure due to non-portability of printf formats like %05.3s)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 06 Nov 2010 14:17:02 +0000

Your bug report

#7325: new test failure due to non-portability of printf formats like %05.3s

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
7325: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7325
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#7325: new test failure due to non-portability of printf formats like %05.3s
From: Pádraig Brady <[email-masked]>
To: Paul Eggert <[email-masked]>
Cc: [email-masked], Eric Blake <[email-masked]>, Jim Meyering <[email-masked]>
Date: Sat, 06 Nov 2010 14:20:50 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

 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

Subject: new test failure due to non-portability of printf formats like %05.3s
From: Jim Meyering <[email-masked]>
To: [email-masked]
Date: Wed, 03 Nov 2010 19:59:44 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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.