Re: [PATCH] Y2038: provide kernel support indication

[Joseph Myers <joseph at codesourcery dot com>]

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@codesourcery.com