Re: Year 2038 problem

[Corinna Vinschen <vinschen at redhat dot com>]

On Nov 19 09:37, Joel Sherrill wrote:
> 
> 
> On 11/19/2015 4:20 AM, Corinna Vinschen wrote:
> >On Nov 19 09:15, Clemens Ladisch wrote:
> >>Corinna Vinschen wrote:
> >>>On Nov 18 11:44, Clemens Ladisch wrote:
> >>>>changing _TIME_T_ to long long
> >>>>[...]
> >>>>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.
> >>
> >>glibc is currently talking about this:
> >>https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
> >>(summary: User code defines _TIME_BITS=64 to ask that 64-bit time be the
> >>default.)
> >
> >For embedded targets we don't have a backward compat problem,
> >typically so I'd prefer a simple solution. which just changes
> >time_t to the prefered type for the target.  But as I just wrote
> >in my reply to Joel, nobody can avoid the year 2038 and at one
> >point everybody will need a 64 bit time_t anyway.
> 
> My only technical concern is performance on 8 and 16 bit targets.
> But there are a couple of realities to consider there.
> 
> (1) As you said, we can't push 2038 back. Suck it up.
> (2) Is an 8/16 bit target really going to use time_t for much?
>     Many RTEMS systems don't even know the calendar time.
>     They are more focused on periodic and interval times.
> 
> 
> I am all for pushing time_t to 64 bits for us. We are tidying up
> a release branch and can move the development master to 64-bit.
> We already use a native internal time format that is better than
> a 32-bit time_t so it is just a matter of double checking any
> conversion math.

Did you see my suggestion?  It was just an idea.  However:

- Do we really still have 8 bit targets?

- How many 8/16 bit targets support 64 bit long long?  Any target not
  supporting 64 bit long long would stay with time_t as 'long'.

> But RTEMS is not a dictatorship. We have a good cooperative
> leadership team and I would like to get feedback from others.
> This is an important issue.

ACK.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpKzZe4Wrj25.pgp
Description: PGP signature