On Fri, 31 May 2024 at 06:07, Jakub Wilk <jw...@jwilk.net> wrote: > > * Jun MO <royclark...@gmail.com>, 2024-05-31 01:05: > >And something "off topic". I find there is a char __glibc_reserved[20] > >variable in the struct utmp, which is commented as "Reserved for future > >use". Just a brainstorm, if this variable is not currently used, maybe > >it can be used to solve the Y2038 problem for wtmp? > > Or, more easily, you could treat the timestamp as unsigned int: > https://sourceware.org/cgit/glibc/commit/?id=5361ad3910c257bc > > "Architectures which use a 32-bit seconds-since-epoch field in struct > lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32, > rv64, x86-64) switched from a signed to an unsigned type for that field. > This allows these fields to store timestamps beyond the year 2038, until > the year 2106. Please note that applications are still expected to > migrate off the interfaces declared in <utmp.h> and <utmpx.h> (except > for login_tty) due to locking and session management problems."
Everybody else is taking advantage of this to switch away from these legacy interfaces - which are really not good and fraught with issues, if we are being honest about it. I don't think it makes sense to invent yet more debianisms just to keep them alive. Just take a backup of existing files and move on.
