This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Year 2038 problem


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

Attachment: pgprbpQh7UOV4.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]