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: Introduction and 64 bit time_t


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]