Fix possible integer overflow in parse_date_time

[a3a3el]

g_date_time_to_unix returns a gint64. Since 27c0728 ("utils: replace time_to_string with fmt-based formatting"), parse_date_time has returned a time_t, which has historically been a 32-bit type. There is, therefore, the possibility of integer over- and underflow. Define TIME_MIN and TIME_MAX based on the size of time_t and clamp the return value of parse_date_time between these.

I'm more a C than a C++ programmer, so I dare say there's a more idiomatic way of doing this that probably looks to me like line noise. :)

[djcb]

std::clamp

[djcb]

Hmm, appreciate the effort, but I don't really want this... mu assumes time_t is 64-bit; if it isn't, your patch won't help getting the correct value for post-2038 dates.

So perhaps better to use 64-bit types everywhere rather than time_t, however, time_t makes the code easier to read.

So perhaps a bulld-time warning? Or even a run-time warning when starting mu?

[a3a3el]

I did look at going back to a 64-bit type, but libfmt expects time_t, so the problem would just have cropped up elsewhere. If you're happy assuming a 64-bit time_t, I'll close the PR. I shall probably carry some version of the patch in Debian, because there are a couple of obscure architectures which lack support for a 64-bit time_t.

[djcb]

Okay... preferably we don't need a patch in Debian.. I've pushed a small change, more-or-less converting your change to in to mu-style c++ :-) .

Of course, it still won't quite work on a 32-bit platform once 2038 hits.

[a3a3el]

On 2024-04-14, at 01:34:32 -0700, Dirk-Jan C. Binnema wrote: Okay... preferably we don't need a patch in Debian..

Thanks!

I've pushed a small change, more-or-less converting your change to in to mu-style c++ :-) .

Fair enough. The bulk of my C++ experience comes from a time when C++98 was still big news. :)

Of course, it still won't quite _work_ on a 32-bit platform once 2038 hits.

Absolutely. Hopefully, in the next fourteen years these architectures will either fix this or become obsolete. J.

[djcb]

Ah, your change wasn't too different, just some minor C++ busywork :)

And yes, by 2038 hopefully all archs have switch to a 64-bit time_t; mu is probably the least of people's worries if they aren't...