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 Aug 11 14:38, Freddie Chopin wrote: > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de wrote: > > However, during the tests I did, I recognized that though > > sizeof(time_t) > > has been 8 now, our software did a wrap-around in January 2038. I was > > able to track it down to gmtime_r where the time_t lcltime gets > > casted > > to long in order to fit into days and rem. > > > > Having days and rem be a time_t and removing the casts fixes the > > wrap- > > around for me, but I highly suspect that this is not a *clean* way to > > do > > it. What are your sugestions on this? Which type should days and rem > > have? > > As the author of the patch that changed gmtime_r() I think I may chime > in. > > The cast in question is just copied from the older version of this > function - _mktm_r() - you may see that in the git history. Why the > cast is there - I have no idea... If you would ask me, I would say to > just remove it. > > "days" and "rem" variables can be both changed to time_t. ACK. Any 'long' in the time code should be replaced with time_t, and useless casts removed. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
signature.asc
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |