Re: [PATCH] Port to 32-bit long + 64-bit time_t

[Paul Smith]

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.