Re: Introduction and 64 bit time_t

["Philipp dot Trommler at preh dot de" <Philipp dot Trommler at preh dot de>]

Am Mittwoch, den 09.08.2017, 13:32 +0200 schrieb Corinna Vinschen:

[snip]

> The newlib functions handling time_t are working fine with 32 and 64
> bit
> time_t, so there's nothing to do to get 64 bit time_t functionality.
> Keep in mind that Cygwin is using 64 bit time_t on x86_64 for quite
> some
> time now.
> 
> "Much", because the way time_t is defined is jusst a tad a bit
> unlucky:
> 
> - time_t is generally typedef'ed to _TIME_T_, so that's good.
> 
> - But _TIME_T_ is indiscriminately defined as long in sys/_types.h
> 
> Only the latter aspect needs rethinking.  In case of 32 bit Cygwin we
> also need to stick to a 4 byte type, unless "somebody(TM)" takes an
> interest and the time to change the Cygwin DLL to 64 bit time_t for
> 32
> bit applications as well.  Lots and lots of wrapping is required to
> keep
> older executables running.

So you're saying that defining _TIME_T_ as long long instead of long
(guarded by conditionals respecting those "old" Cygwin applications and
users who don't want to use a 64 bit time_t) would be enough?

> 
> > 
> > I can't find the email in the rtems.org mailing lists but
> > performance
> > is also an issue. I recall at least two CPUs where 64 bit math
> > performance
> > was bad.
> I wouldn't overvalue that if only a few CPUs are affected.  There's
> always a chance to improve the required math functions for those if
> the level of suffering gets too high.
> 
> > 
> > That said, I think moving to 64-bit time_t is inevitable and
> > mostly overdue. I know RTEMS users have posted about fielding
> > systems with lifespans expected past 2038.
> ACK
> 
> 
> Corinna
>