On 08/11/23 12:44, Thorsten Kukuk wrote: > On Wed, Nov 08, Alejandro Colomar wrote: > >> On Wed, Nov 08, 2023 at 09:59:11AM +0000, Thorsten Kukuk wrote: >>> On Wed, Nov 08, Alejandro Colomar wrote: >>> >>>> strncpy(3) is useful to write to fixed-width buffers like `struct utmp` >>>> and `struct utmpx`. Is there any other libc API that needs strncpy(3)? >>>> Of those two APIs (utmp and utmpx) and any other that need strncpy(3), >>>> are those deprecated, or is any such API still good for new code? >>> >> >> Hi Thorsten! >> >>> Everything around utmp/utmpx/wtmp/lastlog is deprecated. >> >> Is this a Linux-specific thing? Do you know if the BSDs also deprecated >> utmpx? > > Beside the design issues of the interface, which are generic, the Y2038 > issue is more or less glibc specific and a result of supporting 32bit > and 64bit userland at the same time. > For most other implementations I'm aware of there is no Y2038 problem, > either because they don't support utmp/utmpx/... like musl libc, or they > were able to switch to a 64bit time variable or used that already. > So no need to change anything. In fact the glibc utmp y2038 support depends of the ABI, some 64 bit ABIs decided to be compatible with 32 bits so the utmp files could be read/parsed by both ABIs (defined by __WORDSIZE_TIME64_COMPAT32). This required the ut_tv field to be define not as a 'struct timeval', but rather with a similar struct with 32 bit tv_sec (yes, it is a mess and not sure why it was considered a good idea back then). It means that for 64 bits that define __WORDSIZE_TIME64_COMPAT32ABI (mips, riscv, s390, sparc, powerpc, and x86) the utmp ABI is broken regarding y2038 support. The ut_tv is also defined depending of the time_t at build time (_TIME_BITS), so if you have programs with different time_t support, they won't correctly access the utmp (gnulib seems to have some overrides to fix it). Fixing those issues would require a lot of work that I don't think it worth for a API with some inherent implementation flaws [1] (most likely it would require a complete rewrite, which logind basically did). That's why I am leaning to complete remove glibc implementation and mimic what musl did (no-op implementation that return -1/ENOTSUP where applicable). [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24492 > For BSD I don't really know the situation, but as far as I know, they > don't have the problem and thus no need to change anything. > > Thorsten > >> Thanks, >> Alex >> >>> >>> openSUSE Tumbleweed and MicroOS are no longer using nor supporting them >>> and fresh installations don't have that files anymore. >>> So new code should not use utmp/utmp/wtmp/lastlog anymore. Alternatives >>> are e.g. systemd-logind/wtmpdb/lastlog2. >> >> -- >> <https://www.alejandro-colomar.es/> > > >
