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: [PATCH] libc/time/gmtime_r.c (gmtime_r): Fixed bug in calculations for dates after year 2069 or before year 1901


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]