Year 2038 problem

[Corinna Vinschen]

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20151118/a0f44b64/attachment.sig>