Re: Year 2038 problem

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

On 11/18/2015 2:53 PM, Corinna Vinschen wrote:
> On Nov 18 11:44, Clemens Ladisch wrote:
> > Corinna Vinschen wrote:
> > > On Nov 18 07:47, R. Diez wrote:
> > > > I am developing embedded firmware on 32-bit ARM Cortex-Mx processors.
> > > > I believe that there is still no work-around for the year 2038 problem
> > > > in newlib, right?
> > >
> > > What kind of workaround are you looking for?  The usual one is to
> > > redefine time_t as 64 bit type...
> >
> > Is changing _TIME_T_ to long long in newlib/libc/include/machine/types.h
> > and recompiling newlib something that is known to work?
>
> It *should* work,  We're using newlib's time functions on 64 bit Cygwin
> with long being a 64 bit type, so I'm reasonably sure that it should
> work with long long on 32 bit as well.
>
> > Considering the
> > lack of a configuration option for this, I doubt that anybody ever tried.
> >
> > Would such a simple configuration option be accepted into newlib?  (Most
> > embedded systems do not care about backwards compatibility, but newlib
> > as a whole probably does.)
>
> ACK.  And yes, a configuration option is welcome.  It should still
> default to long for backward compat, yes.  32 bit Cygwin is still
> suffering 32 bit time_t as well, but changing that in a backward
> compatible way is quite a big task.

Looking forward for RTEMS, what is the preferred solution long-term?

I recall two solutions:

(1) making time_t a 64-bit
(2) adding time64_t and accompanying methods

IMO (1) is generally preferable when you are building for source and
have no concerns with binary compatibility.

(2) assumes user programs change to use non-standard (but common) APIs.

(1) imposes overhead on 8/16 targets but if they want 2038+ time,
this is really unavoidable.

(2) could be added to newlib in addition to changing time_t to 64
bits on targets that want it. The underlying libgloss calls could
have 64 in the name for targets that have 32-bit time_t. For targets
with 64-bit time_t, the 64-bit time API methods could just wrap
the plain names one.

It is just my opinion but I tend to prefer the simple solution of
making time_t 64-bits where possible. At least for RTEMS.

If we agree we want something more complex, it is possible to define
the requirements as an open RTEMS project and hope a student takes it
on like for the Google Summer of Code. :)

Any thoughts?


--joel