This is a partial fix for problems with 64 bit timestamps on 32 bit
architectures. In certain (not completely understood by me) cases this
casting causes 32bit overflows and yields negative timestamps for
times in the far future.
In g_mime_utils_header_decode_date_unix, there is really no reason to
cast to and from time_t.
In _notmuch_message_set_header_values, we rely on implicit casting of
the argument to Xapian::sortable_serialise to double.
---
This is not a complete fix, but at least the timestamp ends up
aparently correct in the database. It looks like there are still
wonky conversions on reading the large timestamp from the database.
lib/message.cc | 2 +-
util/gmime-extra.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 0fa0eb3a..948626bd 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1217,7 +1217,7 @@ _notmuch_message_set_header_values (notmuch_message_t
*message,
const char *from,
const char *subject)
{
- time_t time_value;
+ gint64 time_value;
/* GMime really doesn't want to see a NULL date, so protect its
* sensibilities. */
diff --git a/util/gmime-extra.c b/util/gmime-extra.c
index 04d8ed3d..af7b6d52 100644
--- a/util/gmime-extra.c
+++ b/util/gmime-extra.c
@@ -192,7 +192,7 @@ gint64
g_mime_utils_header_decode_date_unix (const char *date)
{
GDateTime *parsed_date = g_mime_utils_header_decode_date (date);
- time_t ret;
+ gint64 ret;
if (parsed_date) {
ret = g_date_time_to_unix (parsed_date);
--
2.27.0
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
