Year 2038 problem

[Clemens Ladisch]

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

Related LWN article "The (initial) glibc year-2038 plan":
<https://lwn.net/Articles/664800/>
(If you aren't subscribed to LWN, please subscribe, or wait a week, or
click <https://lwn.net/SubscriberLink/664800/5774103e2c1e971b/> and
consider subscribing.)


While newlib is not compatible with glibc in every detail (in particular,
large file support is incompatible), I think it would be useful and
desirable for the time handling functions.


Regards,
Clemens