[PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t
Paul Eggert
eggert@cs.ucla.edu
Wed Mar 27 20:07:00 GMT 2019
On 3/23/19 4:59 AM, Lukasz Majewski wrote:
> https://github.com/lmajewski/y2038_glibc/commits/mktime_v3_fixes
>
> In short:
>
> - The __time64_t needs to be exported to user space as it is a building
> block for Y2038 safe 32 bit systems' structures (like struct
> __timeval64). In the above use case the "normal" timeval is
> implicitly replaced with __timeval64.
I looked into that URL, and I don't see any explanation of why
__time64_t needs to be visible to user code.
Surely struct timeval ought to be consistent with time_t. That is, it
ought to continue to be defined like this:
struct timeval
{
__time_t tv_sec; /* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
};
where __time_t is merely an alias for time_t and so is 64 bits if
_TIME_BITS=64 and is the current size (32 or 64) otherwise.
The only reason I can see why __time64_t needs to be visible to user
code, would be if a single user source file accesses both time_t and
__time64_t (or needs to access both struct timeval and struct timeval64,
or similarly for struct timespec etc.). However, we should not support a
complicated API like that, as it's typically not useful in practice and
its mere availability causes more confusion than it's worth - as I've
discovered with _FILE_OFFSET_BITS and __off64_t. Instead, glibc should
have a simple user API where _TIME_BITS=64 merely says "I want 64-bit
time_t everywhere" and a module either uses this option or it doesn't.
I did see a fix in that URL, to use "#elif defined TIME_T_IS_SIGNED"
instead of "#elif TIME_T_IS_SIGNED" for the benefit of picky glibc
compiles, and that fix is incorporated in the revised patch attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-mktime-etc.-compatible-with-__time64_t.patch
Type: text/x-patch
Size: 17777 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190327/7d79bde6/attachment.bin>
More information about the Libc-alpha
mailing list