This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v10] y2038: Provide conversion helpers for struct __timespec64


On Wed, 4 Dec 2019, Dmitry V. Levin wrote:

> Unfortunately, this didn't work out as intended because Linux kernel prior
> to commit 7b8474466ed97be458c825f34a85f2c2b84c3f95 (including released
> version v5.4) did not zero the upper 32-bits of tv_nsec on 32-bit
> architectures, which means that we have to do it in
> valid_timeval_to_timespec64 and valid_timespec_to_timespec64 instead.

"have to do it in valid_timeval_to_timespec64 and 
valid_timespec_to_timespec64" can't be the answer.

Remember that all the functions using 64-bit time are intended in future 
to be user-visible functions that will be called directly by user code 
with _TIME_BITS=64.  That is, it is those functions that have to handle 
the padding being uninitialized.  And so it is those functions, receiving 
64-bit-time structures on input, that have to copy the structures (many 
can legitimately be called with inputs in read-only memory, they can't 
write to the inputs unless the definition of the function semantics says 
they can) and zero the padding if supporting kernels that don't do so 
themselves - not any callers that convert from 32-bit.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]