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 Dec 7 19:33, Freddie Chopin wrote: > Hello! > > It turns out that the implementation of gmtime_r() with my modifications > from September has a bug... > [...] > As a possible optimization, > quite a lot of the code can be removed for platforms where time_t is 32-bit > long, but that's another thing. The problem is, platforms with 32 bit time_t will run into trouble sooner than later. I'm not so sure it's still worth to optimize for 32 bit time_t. To the contrary, we might be better off in future to change the time_t typedef to int64_t instead of long. Does anybody have a strong opinion here? > BTW - are there any platforms which have time_t as a 64-bit variable that > use newlib, that would be affected by this problem? Every 64 bit platform with sizeof(long) > 4. 64 bit Cygwin, for instance. > 2014-12-07 Freddie Chopin <...> > > * libc/time/gmtime_r.c (gmtime_r): Fixed bug in calculations for dates > after year 2069 or before year 1901. Ideas for solution taken from > musl's __secs_to_tm() Patch applied. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpqj1_aCC1oN.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |