[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: Pádraig Brady
Subject: bug#7325: new test failure due to non-portability of printf formats like %05.3s
Date: Wed, 03 Nov 2010 23:42:44 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

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 023xxxxxx nanoseconds.
So what is 23 in that context?

> And I agree that we'd have to trim off the 0 modifier before calling the 
> underlying
> printf %s, and thus be responsible for putting in '0' padding ourselves
> rather than relying on printf() padding.

I'd just strip any leading 0 if a precision is specified,
to suppress the problematic solaris behavior.


reply via email to

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