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 22, 2016 8:19:36 PM CEST Joseph Myers wrote:
> 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.)

Just for my understanding: do you mean requiring new headers specifically
for building with _TIME_BITS=64 as I said, or would you change the minimum
kernel header version for building glibc in general when we merge 64-bit
time_t support?

> (_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.)

Fair enough. And this would also mean that we don't allow 32-bit
time_t on future architectures ports that never had an upstream Linux
kernel without 64-bit time_t interfaces, right?

On a related note, is there still a plan to allow building a glibc
with 32-bit time_t disabled? I asked for that to be included in the
past, but I don't see it in the Albert's document now, so I'm guessing
that it was intentionally removed again.


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