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
prev parent reply other threads:[~2023-03-03 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-03 10:46 Y2038, glibc and utmp/utmpx on 64bit architectures Thorsten Kukuk
2023-03-03 16:51 ` A. Wilcox
[not found] ` <3067bd0ec5134b039cdb8be9db8da8e5@DB6PR04MB3255.eurprd04.prod.outlook.com>
2023-03-03 17:07 ` Thorsten Kukuk
2023-03-03 20:09 ` Anna
2023-03-03 20:25 ` Bruno Haible
[not found] ` <c420abff6abd43cabac8c2fa5d812091@DB6PR04MB3255.eurprd04.prod.outlook.com>
2023-03-03 20:55 ` Thorsten Kukuk
2023-03-03 22:11 ` Bruno Haible [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2900303.CPfdCl3LZh@nimes \
--to=bruno@clisp.org \
--cc=distributions@lists.linux.dev \
--cc=eblake@redhat.com \
--cc=kukuk@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.