On Wed, 5 Dec 2018, Arnd Bergmann wrote: > That would make it very hard to deploy a glibc based system > with strict y2038 requirements. If we can no longer guarantee the > basic assumption that old applications keep using the old system > calls, then I think we instead need a way to build glibc itself without > support for the 32-bit time_t interfaces, e.g. using a --disable-time32 > configuration switch to force a link-time error for any application > or library that has not been built against the 64-bit time_t interfaces. (There's never been a guarantee of keeping using the same system calls. Cf. people trying to restrict the system calls some code can use and running into issues with moves to use e.g. *at syscalls unconditionally on all architectures to implement the non-*at functions.) The set of interfaces that involve 32-bit time_t or other structures including it is well-defined; an external checker can examine the dynamic symbol table of any dynamically linked 32-bit application or shared library to see if it has references to any of the symbols in question, without needing to run the code at all (and so detect issues in code that might not be frequently executed, not just in whatever code runs when you're testing for 32-bit time uses). (Or if you control the build of the whole system, do a local change to make a glibc header use #error if _TIME_BITS is not defined to 64.) I'd expect it to be a long time before we might consider making 32-bit time_t (and thus 32-bit off_t) subject to something like --enable-obsolete-rpc / --enable-obsolete-nsl being needed to make the 32-bit interfaces available at (static) link time at all. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx
