[glib: 25/26] gmain.c: Fix comment about Y2038 safety of g_get_real_time()
- From: Philip Withnall <pwithnall src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [glib: 25/26] gmain.c: Fix comment about Y2038 safety of g_get_real_time()
- Date: Mon, 29 Jul 2019 13:02:24 +0000 (UTC)
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]