Re: lua32: Any easy fix for 2038 problem of os.time?

[Flyer31 Test <flyer31@...>]

I am talking of Lua 5.4. But I use a 32bit C compiler - in Keil ARMCC
which I use, time_t in time.h is used as "unsigned long", so 32bit
UNSIGNED ... but anyway this will stop latest on 2090 or so ... and I
am quite sure that some Lua users could somehow easily mixup after
2038, as they are used from Lua that os.time works with singed
numbers.

As I see it, you could adapt a shifted time_t to Lua32 by "simple
shifting time_t" only, if the basic compiler functions work with
"time_t of 64bits" ... but Keil ARMCC does NOT support this (at least
not in microlib environment) ... (otherwise in time.h they would
present some possibility to define time_t as "long long", but I see
nothing like this ... also I think it really the "date problem" is no
sufficiently pressing problem to enforce to implement 64bit
arithmetics into a 32bit controller...).

On Tue, Aug 10, 2021 at 8:48 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > For Lua32, as well as for Linux32, this 2038 problem of os.time is really
> > quite nerving.
> >
> > [...]
> >
> > In my own "practical approach" I would now not count the number of seconds,
> > but the number of 8 seconds - [...]
>
> What version of Lua are you talking about? In 5.4, it should be easy
> to change how you convert the "internal" representation of time (time_t)
> and the "external" representation of time (lua_Integer), so a single
> shift would solve your problems for Lua32. For Linux32, any solution
> seems to be outside the Lua realm.
>
> -- Roberto