Re: Y2038, glibc and utmp/utmpx on 64bit architectures

From: Bruno Haible <bruno@clisp.org>
To: distributions@lists.linux.dev, Thorsten Kukuk <kukuk@suse.com>
Cc: Eric Blake <eblake@redhat.com>
Subject: Re: Y2038, glibc and utmp/utmpx on 64bit architectures
Date: Fri, 03 Mar 2023 23:11:49 +0100	[thread overview]
Message-ID: <2900303.CPfdCl3LZh@nimes> (raw)
In-Reply-To: <20230303205500.GA13773@suse.com>

Thorsten Kukuk wrote:
> > Do the glibc developers plan to remove the utmpx
> > interface as well (together with utmp interface)?
> 
> In glibc, utmpx is just an alias for utmp.
> 
> > If yes, then
> >   - What is the point of your suggestion to "use the utmpx and not utmp
> >     interface", above?
> 
> utmps only supports the utmpx interface, not utmp. So if you want to use
> utmps, you need to convert all source code to utmpx.

Thanks for the explanations. It's clear now.

> >   - Since there is no "FUTURE DIRECTIONS" in POSIX
> >     https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/endutxent.html
> >     will the utmpx interface get deprecated in POSIX, or stay as it is?
> >     Is the Austin Group already involved?
> 
> Linux is not POSIX conform, never was and there was never the plan to
> become, but it tries to be as compatible with POSIX as possible where
> it makes sense. If it does not make sense, POSIX will not be used. You
> should be able to find several examples in glibc, where interfaces
> derivate slightly from POSIX because the POSIX interface didn't made any
> sense.
> Parts of POSIX are really old (don't know how old utmp/utmpx are, but
> they did exist already since a long time before I started to work
> with Unix, and that's really a long time ago) and things are changing.
> Today, utmp/utmpx create more problems then it solve. Many features of
> it where never used on Linux or are meanwhile no longer used, at least
> not with systemd.
> There is just no benefit from it anymore. ...

I don't disagree with that.

Just that, as part of keeping Linux + glibc as close a possible to POSIX
over the long term, when we remove a feature from glibc that is POSIX-
standardized, we should also remove (or at least mark as LEGACY) this
part from POSIX. POSIX evolves, partially based on our inputs. I don't see
the deprecation of [1][2] on the Austin Group's agenda so far [3].

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/utmpx.h.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/endutxent.html
[3] https://www.austingroupbugs.net/view_all_bug_page.php