[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Smith
Subject: Re: [PATCH] Port to 32-bit long + 64-bit time_t
Date: Sun, 02 Oct 2022 17:09:20 -0400
User-agent: Evolution 3.44.4 (by Flathub.org)

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
   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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]