Re: Second draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 29 Jan 2016, Arnd Bergmann wrote:

> Should the kernel rely on the glibc-specific "_TIME_BITS" for this,
> or do we define some other macro that the kernel can test for?

Note that _TIME_BITS would not be tested directly in most glibc headers; 
it would be tested in features.h and used there to define __USE_* macros.  
(This is an observation, not an answer to your question.)

> __kernel_time_t, ...) and avoids namespace conflicts. In all the above
> examples, the new structure is identical between 32-bit and 64-bit
> architectures. [background: this lets us have a common syscall
> implementation for 64-bit and new 32-bit interfaces, while the

To reiterate on identical structures: where nanoseconds are involved in 
struct timespec or anything else where POSIX requires "long" to be the 
type, it's a pain for glibc if the kernel treats them as a 64-bit value 
when coming from a 32-bit process, as opposed to a 32-bit value with 32 
bits of padding, because then glibc needs to copy user-provided structures 
and sign-extend the nanoseconds value before passing it to the kernel.  
(But for 64-bit processes, correct error checking requires that the value 
be treated as 64-bit.)  (This doesn't apply to timeval because that uses 
suseconds_t for microseconds.  But I'd also suppose that syscalls 
involving timeval would generally be considered deprecated and the 64-bit 
replacements would be using timespec.)

-- 
Joseph S. Myers
joseph@codesourcery.com