Re: Introduction and 64 bit time_t

[Corinna Vinschen <vinschen at redhat dot com>]

On Aug  9 12:17, Philipp.Trommler@preh.de wrote:
> 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'd prefer to use the type long on LP64 systems, but long long should
work fine for all 32 bit systems (baring 32 bit Cygwin).

However, a developer might want to design an embedded system still using
a 32 bit time_t for the time being, so there should be some build-time
switch for this case.  We're talking about a 21 year timeframe, which
may still be more than enough for some systems.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature