Re: Year 2038 problem

[Corinna Vinschen <vinschen at redhat dot com>]

On Nov 18 15:54, Joel Sherrill wrote:
> 
> 
> 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.

Yes, indeed.  The problem is just that some systems might want to stay
on 32 bit for a while longer, but in the long run there's no way around
moving time_t to a 64 bit type anyway.  I don't believe we can push off
the year 2038 indefinitely :)

> (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.

ACK.  Same for Cygwin in theory, but there the problem of backward
compatibility hits us hard, so we have to stick to 32 bit time_t
for a while longer :(

In theory we could probably get away with something like this:

  #ifdef __CYGWIN__ /* TODO: Move 32 bit Cygwin to 64 bit time_t */
    #define _TIME_T_ long	
  #elif __have_long32 && __have_longlong64
    #define _TIME_T long long
  #else
    #define _TIME_T long
  #endif


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpBZ75EdYfxw.pgp
Description: PGP signature