[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: Fri, 05 Nov 2010 01:05:32 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

On 04/11/10 20:10, Paul Eggert wrote:
> On 11/04/10 00:56, Jim Meyering wrote:
>> However, what about Eric's example?
>>   $ src/stat-p -c '_%-0 010.4:X_' k  # yours
>>   _234       _
>>   $ src/stat-j -c '_%-0 010.4:X_' k  # mine
>>   _0234      _
> That's simply an issue of whether the value is considered to be signed
> or unsigned, and can be fixed by the patch at the end of this message.
> However, let me take a step back a minute.  Do users really want all
> this functionality?  Personally, what I'd like to see is a single
> format like this:
>    %.3X
> that prints out the entire seconds since the Epoch, truncated
> to millseconds.  That's simpler than what we require now:
>    %X.%.3:X
> The changelogs suggest that we used to do things the simpler way,
> but changed on Oct. 21.  I don't recall this being discussed: I 
> assume it was due to floating point rounding issues.  Still, I'd
> prefer the simpler notation, and we should be able to implement it
> without floating point.  Would that be OK?  The idea would be
> to support ".PRECISION" in the formats for W, X, Y, and Z, and
> to drop support for ':W' and the like.

I think you're echoing my suggestion here:
Given the counter arguments there it was decided to
split to X and :X etc.

I still slightly prefer just using %.X as
it's backwards compat with older coreutils (excluding 8.6).


reply via email to

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