This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fourth draft of the Y2038 design document

On Wednesday, June 29, 2016 1:16:11 PM CEST Albert ARIBAUD wrote:
> On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann <>
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]