Re: "pr -D FORMAT" fixes, to match "date +FORMAT"

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> -      sprintf (buf, "%ld.9d", (long int) s, ns);
> +      sprintf (buf, "%ld.%09d", (long int) s, ns);

Ouch.  Thanks for catching this.

> do you know how to create a file with
> e.g. 64-bit st_mtime

"touch -d @9223372036854775807 /tmp/foo" should do it.  I just now did
it successfully on 64-bit Solaris 9 (sparc), with GNU coreutils (CVS
version) "touch" and with /tmp mounted on swap using tmpfs.

> so that makes localtime fails?

Unfortunately, Solaris 9 localtime does not fail (as it should) on
out-of-range time_t values.  Instead, it produces garbage results.  I
suspect that this may be a fairly common bug in practice, so it may be
a bit of a pain to come up with a portable test case in this area.

Also, the standard Solaris executables (e.g., "/usr/bin/rm",
"/usr/bin/ls") do not work on files whose time stamps do not fit into
a 32-bit signed time_t.  That is because they are compiled in 32-bit
mode, and only 64-bit executables can access such files.  This is
another argument against having test cases with outlandish file time
stamps.


> I tried using a very large value on Solaris 9, but utime fails
> with EOVERFLOW (which isn't mentioned in Solaris man pages as one of
> the ways utime may fail).  utimes works the same way.

Most likely you were trying it on a file system that doesn't support
64-bit time_t.  Try it on /tmp, say; that should work if you're using
tmpfs.