[glib: 25/26] gmain.c: Fix comment about Y2038 safety of g_get_real_time()



commit 14b087ea18ef0d1d3b5338bb3455a9f7e08da815
Author: Philip Withnall <withnall endlessm com>
Date:   Fri Jul 26 20:31:42 2019 +0100

    gmain.c: Fix comment about Y2038 safety of g_get_real_time()
    
    This comment was correct until commit adf1f98f62, when the `GTimeVal`
    which the result was put into (introducing the Y2038-unsafety) was
    dropped.
    
    The adjustment and scaling of the `FILETIME` should not make it
    Y2038-unsafe: the maximum `FILETIME` is 2^64-1. Subtracting the epoch
    adjustment and dividing by 10 gives the timestamp 1833029933770955161,
    which is in June 58086408216 (at just after 3am UTC). I think that’s
    enough time to be going on with.
    
    Signed-off-by: Philip Withnall <withnall endlessm com>
    
    Helps: #1438

 glib/gmain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/glib/gmain.c b/glib/gmain.c
index 90b12411d..af979c8b8 100644
--- a/glib/gmain.c
+++ b/glib/gmain.c
@@ -2686,7 +2686,7 @@ g_get_real_time (void)
   memmove (&time64, &ft, sizeof (FILETIME));
 
   /* Convert from 100s of nanoseconds since 1601-01-01
-   * to Unix epoch. Yes, this is Y2038 unsafe.
+   * to Unix epoch. This is Y2038 safe.
    */
   time64 -= G_GINT64_CONSTANT (116444736000000000);
   time64 /= 10;


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