GNU bug report logs - #7325
new test failure due to non-portability of printf formats like %05.3s

Previous Next

Full log

Message #20 received at 7325 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7325 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#7325: new test failure due to non-portability of printf
	formats like %05.3s
Date: Wed, 03 Nov 2010 23:42:44 +0000

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.

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.