This is the mail archive of the
mailing list for the glibc project.
Re: Fourth draft of the Y2038 design document
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: libc-alpha at sourceware dot org, Y2038 <y2038 at lists dot linaro dot org>
- Date: Wed, 29 Jun 2016 13:16:11 +0200
- 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>
On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann <email@example.com>
> On your note "The implementation needs further thinking about, as
> application code defining _TIME_BITS=64 and gets built against
> new kernel headers and old GLIBC headers, then GLIBC will use 32-bit
> time_t and kernel will expect 64-bit time_t, and there is no way
> to ensure detection of this case.", I think that is covered by
> having the kernel headers check __USE_TIME_BITS64 instead of
> _TIME_BITS=64, as I described above.
What about application source code which includes kernel headers before
including any GLIBC header? The kernel header will see __TIME_BITS=64
but it won't see _USE_TIME_BITS64, and will make the wrong decision.
Don't we consider this a possible scenario?