This is the mail archive of the
mailing list for the glibc project.
Re: Second draft of the Y2038 design document
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: <libc-alpha at sourceware dot org>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Date: Fri, 29 Jan 2016 15:40:13 +0000
- Subject: Re: Second draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160128204114 dot 6c7dbbf7 dot albert dot aribaud at 3adev dot fr> <12761061 dot sGnHL6NOhT at wuerfel>
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