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] |
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] |