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

Previous Next

Full log

View this message in rfc822 format

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Paul Eggert <eggert <at> CS.UCLA.EDU>, 7325 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: bug#7325: new test failure due to non-portability of printf formats like %05.3s
Date: Mon, 08 Nov 2010 09:02:03 -0700

[Message part 1 (text/plain, inline)]

On 11/08/2010 08:22 AM, Pádraig Brady wrote:
> On 08/11/10 14:33, Jim Meyering wrote:
>> Looks like I got very lucky here and hit a number of nanoseconds
>> that happened to be a multiple of 100,000:
>>
>>     $ for i in $(seq 1000); do touch -d '1970-01-01 18:43:33.5000000000' 2; t=$(stat -c "%.W %.X %.Y %.Z" 2); test $(echo "$t"|wc -c) -lt 57 && echo "$t"; done
>>     0.000000 63813.500000 63813.500000 1289224045.731146
>>     0.0000 63813.5000 63813.5000 1289224047.8224
>>     [Exit 1]
>>
>> I realize this is due to the way the precision estimation
>> heuristic works.  Wondering if there's a less-surprising
>> way to do that.
> 
> You could snap to milli, micro, nano,
> though that would just mean it would
> happen less often.

On cygwin, the default precision is 100nano (that is, 7 digits).

See also gnulib/lib/utimecmp.c, which also sets up a hash table that
tries to determine a file system's default resolution.  In particular,
it makes 100% correct analysis on file systems that support
_PC_TIMESTAMP_RESOLUTION, but that's still pretty rare today.

In fact, since Paul originally wrote utimecmp.c, I'm surprised that you
rewrote the coreutils hash table from scratch rather than trying to
reuse the code.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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