Re: Year 2038 problem

[Corinna Vinschen <vinschen at redhat dot com>]

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

Attachment: pgpgfv5clCwiu.pgp
Description: PGP signature