Re: Any thought to making time_t 64 bits?

[Eric Blake <ebb9 at byu dot net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Schwarz, Konrad on 9/21/2009 12:48 AM:
>> Eric Blake just sent a query to the cygwin mailing list asking
>> if there had been any thought given to making time_t 64 bits.
> 
> Without having looked at newlib from this angle, can't we have both? :-)

Adding 64-bit time while keeping 32-bit time is certainly doable.  And in
the case of cygwin, that is certainly what we want.  Just look how open64
was added alongside open for off_t size changes (newlib has an opaque
_off_t used internally, which cygwin augments with _off64_t, then the
public typedef for off_t can be set to the desired size).  Another example
is stat, where cygwin has __stat32 and __stat64 under the hood for
accommodating the change in size of off_t.  Meanwhile, newlib should
continue to offer at least the configuration option of only 32-bit time_t,
for embedded systems where speed and space are more important than 2038
time wraparound.

The current idea of adding __time64_t under the hood has some interesting
ramifications; for example, stat64 with 32-bit time is no longer adequate,
so we would now have to add a new struct __stat64x and yet another stat
wrapper for backwards compatibility for existing apps linked against the
32-bit API, while providing the 64-bit API to new apps.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq3cAUACgkQ84KuGfSFAYAnEwCfe/fO8zTL3z/x/qDcz9Hm+5ZG
wC0AmgIqSvnz8oHOgpvikRyscHVkTIpn
=BcXM
-----END PGP SIGNATURE-----