On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> On 9/21/22 23:49, Eli Zaretskii wrote:
> > This will cause problems in the native MS-Windows builds, where
> > printf in the system C runtime doesn't support %lld and %llu.
>
> Thanks for the review. Revised patch attached. It also addresses your
> comment about the commit message, plus it fixes a couple of places
> where I mistakenly used PRI* macros instead of SCN* macros.
Are there really any AR format standards that use timestamps >32bits?
Maybe so. Note that for ar support (most of it anyway) we don't care
what the size of time_t is, we only care about how large the value that
could appear in an archive's modification time field is.
I applied these changes but made a few mods:
Instead of _PRI64_PREFIX I used MK_PRI64_PREFIX because the former is a
reserved preprocessor token for the system.
Wherever we used string concatenation I added a space between the
string and the token: I realize in C it doesn't matter but in C++ it
can matter and so I prefer to just use the same format everywhere.
I had a question about this change:
@@ -1018,13 +1018,16 @@ file_timestamp_sprintf (char *p, FILE_TIMESTAMP
ts)
struct tm *tm = localtime (&t);
if (tm)
- sprintf (p, "%04d-%02d-%02d %02d:%02d:%02d",
- tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
- tm->tm_hour, tm->tm_min, tm->tm_sec);
+ {
+ intmax_t year = tm->tm_year;
+ sprintf (p, "%04" PRIdMAX "-%02d-%02d %02d:%02d:%02d",
+ year + 1900, tm->tm_mon + 1, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+ }
Is this really needed? Is there ever a system anywhere that can't
represent any remotely useful year value using an int (even if you add
1900 to it :) )? The POSIX spec, for sure, defined the struct tm
tm_year data member to be of type int.
