This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Any thought to making time_t 64 bits?
On Mon, Sep 21, 2009 at 06:22:29AM -0600, Eric Blake wrote:
>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.
Right, Cygwin would need to have a split personality since we don't want
to force recompilation of everything. So we'd undoubtedly need two of
every function which manipulates time.
I guess that means that newlib would also need to somehow allow two of
any function that manipulates time_t, too.
I think I have to take back my assertion that Cygwin 1.7 would be the
time to do this. It seems like it would be too much work at this stage
in the release. But it would be nice, if people are interested, to start
thinking about adding this functionality to newlib soon, regardless.
cgf