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 [email protected] _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
