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: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigBrady.com>, 7325 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: bug#7325: new test failure due to non-portability of printf formats like %05.3s
Date: Tue, 09 Nov 2010 07:54:30 +0100

Paul Eggert wrote:

> On 11/08/10 08:02, Eric Blake wrote:
>> 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.
>
> I had vaguely remembered the issue, but I had forgotten where I put
> that code.  utimecmp.c modifies the time stamp of the files, right?
> So it might not be a good idea here.  But perhaps some of the common
> code could be factored out.
>
> Getting back to the point: I don't see a problem with 'stat' backward compatibility.
> The guessed-resolution time stamps are output only if someone uses "%.X",
> which is a format that nobody would use before the change.  So old
> scripts shouldn't be broken by the change.
>
> So it sounds like the issue is mostly about new scripts.  But for

Yes.

> those, we can tell people not to use "%.X" if they want to do textual

The semantics of this feature feel rather involved for something that
looks like a simple default.  Some will not read the caveat.

> comparison.  Advice along these lines will be needed no matter what,
> because, even if we could determine timestamp resolution perfectly,
> there would still be a problem with blind use of "%.X".  Suppose someone
> did something like this:
>
> 	ts=$(stat -c %.Y $old)
> 	cp -p $old $new
> 	# Wait for $new to be modified
> 	while [ $ts = $(stat -c %.Y $new) ]; do sleep .1; done
>
> This won't work as desired even if stat could deduce timestamp resolution
> perfectly, because $old and $new could be on different file systems,
> and $new's file system could have a coarser resolution than $old's.
>
> I can write a documentation patch along these lines if you like.

Isn't this a good reason to attach the variable-width functionality
to a less-likely-to-be-(ab)used syntax like "%#.X"?  Then we would put
that format directive in the default format string, where its output
is parsed only by humans, and scripts using the shorter %.X
would be less error prone.

Previous Next

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