This is the mail archive of the
mailing list for the glibc project.
Re: Fourth draft of the Y2038 design document
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Y2038 <y2038 at lists dot linaro dot org>
- Date: Wed, 29 Jun 2016 16:02:13 +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> <20160629131611 dot 5d55ed3f dot albert dot aribaud at 3adev dot fr>
On Wednesday, June 29, 2016 1:16:11 PM CEST Albert ARIBAUD wrote:
> On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann <email@example.com>
> wrote :
> > 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?
Good point, I think you are right that this is a problem. In particular,
the normal rule for kernel headers is that they should explictly not
include any libc headers or rely on them to be included first. We have
some exceptions from those rules for historic reasons.
Do you have any other ideas for how to solve it? We probably only
need a handful of those, so we could look at them case-by-case to
see what kind of exception we can make.