This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fourth 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>, Y2038 <y2038 at lists dot linaro dot org>
- Date: Wed, 22 Jun 2016 20:19:36 +0000
- Subject: Re: Fourth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160622005838 dot 60a95c44 dot albert dot aribaud at 3adev dot fr> <4435377 dot 8hJ2GQPYUg at wuerfel> <alpine dot DEB dot 2 dot 20 dot 1606221418100 dot 29819 at digraph dot polyomino dot org dot uk> <6204150 dot Ja8izhmCjv at wuerfel>
On Wed, 22 Jun 2016, Arnd Bergmann wrote:
> We can avoid most of the problems if building with _TIME_BITS=64
> has no effect unless both glibc and the kernel headers are new
> enough to provide the definitions for 64-bit time_t. That way
> we can at least ensure that calling an ioctl command or setsockopt
> with an incompatible ABI will result in an error code rather than
> wrong data.
I'd be a lot more comfortable with requiring new kernel headers to build
and use glibc than with requiring a new kernel at runtime for
_TIME_BITS=64 to work. New kernel headers are one of the easiest things
to use when building glibc, since we have the --with-headers option. (In
fact right now the headers requirement (3.2) is newer than the runtime
requirement (2.6.32) on x86_64 / x86.)
(_TIME_BITS=64 should of course be an OS-independent API, supported for
all glibc configurations. Obviously exactly what Hurd does is up to the
Hurd maintainers, as probably is fixing Hurd to keep it working with
_TIME_BITS=64, but _TIME_BITS=64 should clearly enable 64-bit time_t for
it even if some underlying Y2038-safety is missing. NaCl already has
64-bit time_t so _TIME_BITS=64 would have no effect there.)
--
Joseph S. Myers
joseph@codesourcery.com