Year 2038 problem

[Corinna Vinschen]

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.


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/20151119/b9be59bb/attachment.sig>