Introduction and 64 bit time_t

[Philipp.Trommler@preh.de]

Am Freitag, den 11.08.2017, 15:42 +0200 schrieb Corinna Vinschen:
> 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.

I'll do this and post a patch afterwards.

Philipp