[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7325: new test failure due to non-portability of printf formats like

From: Paul Eggert
Subject: bug#7325: new test failure due to non-portability of printf formats like %05.3s
Date: Thu, 11 Nov 2010 09:54:14 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

On 11/11/2010 07:24 AM, Eric Blake wrote:
> %.0X as a mnemonic of 'show full precision but suppress
> trailing zeros' kind of makes sense

I had considered supporting those semantics
as well, which would have avoided all this business with
fstimeprec.  That is, just trim trailing zeros, and don't
worry about the file system time stamp resolution.  The problem
with this approach is that different time stamps for the same
file (atime, mtime, ctime) might show different numbers of digits,
which might cause alignment problems and confusion.

I'm a bit leery of %.0X as meaning "show more than zero digits
of precision", since .0 always means show zero everywhere else
that printf-style formats are used.

I'm still not quite following the backward compatibility argument,
as no matter what we do, we'll have different functionality than
before.  %#.X outputs an integer time stamp with coreutils 5.97
and outputs nothing with coreutils 8.6.  %.0X is the same as
%#.X, so they're both equally "bad" in that respect.  %.*X outputs
"*X" with 5.97 and "?X" with 8.6, so it's not portable either.  It's
not a big deal, but I still mildly prefer the * notation.

By the way, while we're on the subject (:-), 'stat' uses wildly
different strategies when dealing with invalid formats.
Sometimes it outputs a diagnostic, sometimes it silently
outputs a question mark, sometimes it silently outputs the format itself.
At some point somebody should rationalize this.  I suggest having
'stat' output the format itself, as that makes diagnosis easy and

reply via email to

[Prev in Thread] Current Thread [Next in Thread]