Add missing utmpx apis for linux musl

[Ecordonnier]

Description

Add the utmp APIs which were missing from musl.
Close #4322

Sources

This is based on https://git.musl-libc.org/cgit/musl/tree/include/utmpx.h
Note that musl implements only stub functions for utmp functionalities, because they consider it unsafe.

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget); (unrelated error about #include <linux/errqueue.h>)
  especially relevant for platforms that may not be checked in CI

Signed-off-by: Etienne Cordonnier [email protected]

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Ecordonnier]

It compiles and I tested it by building uutils-coreutils with it as dependency, however I haven't managed to run cargo test on ubuntu 24.04:

~/dev/libc/libc-test$ cargo test --target x86_64-unknown-linux-musl
   Compiling proc-macro2 v1.0.94
   Compiling unicode-ident v1.0.18
...
   Compiling libc-test v0.1.0 (/home/ecordonnier/dev/libc/libc-test)
The following warnings were emitted during compilation:

warning: [email protected]: src/errqueue.c:2:10: fatal error: linux/errqueue.h: No such file or directory
warning: [email protected]:     2 | #include <linux/errqueue.h>
warning: [email protected]:       |          ^~~~~~~~~~~~~~~~~~
warning: [email protected]: compilation terminated.

Do you know what the issue is? I do have the required header-file:

~/dev/libc/libc-test$ ls /usr/include/linux/errqueue.h 
/usr/include/linux/errqueue.h

[Ecordonnier]

Please also consider this for backporting to 0.2

[Ecordonnier]

@rustbot label +stable-nominated

[Ecordonnier]

The header-file error seems to be a generic error when compiling with musl-gcc:
https://www.reddit.com/r/rust/comments/mo3i08/comment/gubgh33/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

https://stackoverflow.com/questions/42128091/linking-to-musl-with-other-headers-from-usr-include

[tgross35]

Considering musl's stance here, what failures motivate this addition? It seems like the API consumer may be better off disabling utmpx functionality on musl rather than having surprising untested nop behavior, and I'm wondering if we wouldn't be better off leaving these undefined to discourage running into that footgun.

If you still think this is worth having, it would be preferable to move the existing definitions from linux/gnu/mod.rs to linux/mod.rs so glibc, musl, and uclibc all get covered.

[Ecordonnier]

@tgross35 I understand your concern. I was thinking about this as well before the implementation and was hesitating as well. However my reasoning for including it in libc is the following:

• IMO the libc crate should provide exactly what musl is providing, and not make its own decisions on excluding certain functions, because this introduces even more complexity for developers (then they need to know not only the implementation of musl, but the implementation of the libc crate as well). The musl library took the decision to publish those functions as stub, and as a transparent wrapper I think the libc crate should provide those as well.

• my motivation for this addition is that uutils-coreutils does not compile for musl because of those missing definitions ( problem building some programs on musl uutils/coreutils#1361 ). It is easily possible to exclude some utilities for musl at install time if desired (the coreutils utillities using utmpx are "pinky", "uptime", "users", "who"), but it is desirable to be able to compile everything with musl, since the goal of the uutils coreutils project is to have 100% parity with the C coreutils project, and thus have the exact same behavior than GNU coreutils (written in C) compiled with musl (there is code in uutils coreutils handling the errors of the utmpx functions and printing some error messages, so being able to compile those functions would avoid adding "[cfg(not musl)]" lines above each call to a utmpx function).

Regarding your request to make those generic, please note that since constants are prefixed with "__" in glibc, but not in musl, the constant is e.g. "UT_HOSTSIZE" in musl, but "__UT_HOSTSIZE" in glibc. Do you want me to move a subset to the generic file?

[tgross35]

I think bug-for-bug tools like uutils are probably somewhat on the rare side. Maybe let's do this: we can add the functions but immediately mark them deprecated so the user is likely to get a warning. That way they are available if needed but less likely to be used by complete accident, and uutils or anyone who expects the behavior can just silence the lint on a case-by-case/function/module basis.

// NB: not actually intended for removal; this is a user warning that the function may not
// behave as expected
#[deprecated(since="0.2.172",
    note="musl provides `utmp` as stubs and an alternative should be preferred; see \
    https://wiki.musl-libc.org/faq.html"
)]

If that sounds reasonable, would you mind adding the same attribute to other functions that musl has stubbed out?

Regarding your request to make those generic, please note that since constants are prefixed with "__" in glibc, but not in musl, the constant is e.g. "UT_HOSTSIZE" in musl, but "__UT_HOSTSIZE" in glibc. Do you want me to move a subset to the generic file?

Didn't realize that, nope it's fine!

[Ecordonnier]

I think it is a good idea. I have added the deprecation warnings using a macro. I've also tested that the warnings are printed when compiling uutils-coreutils:

ecordonnier@LC49NTQ3:~/dev/coreutils$ cargo build --target  x86_64-unknown-linux-musl -p uu_users
   Compiling libc v1.0.0-alpha.1 (/home/ecordonnier/dev/libc)
   Compiling uucore v0.0.30 (/home/ecordonnier/dev/coreutils/src/uucore)
warning: use of deprecated function `libc::endutxent`: musl provides `utmp` as stubs and an alternative should be preferred; see https://wiki.musl-libc.org/faq.html
  --> src/uucore/src/lib/features/utmpx.rs:43:15
   |
43 | pub use libc::endutxent;
   |               ^^^^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default
   ...

Edit: I've removed the macro because the CI was failing

+macro_rules! deprecated_utmpx {
+    ($( $vis:vis fn $fn:ident $args:tt $(-> $ret:ty)?; )*) => {
+        $(
+            #[deprecated(
+                since = "0.2.172",
+                note = "musl provides `utmp` as stubs and an alternative should be preferred; see https://wiki.musl-libc.org/faq.html"
+            )]
+            $vis fn $fn $args $(-> $ret)?;
+        )*
+    };
+}
+
 extern "C" {
     pub fn sendmmsg(
         sockfd: c_int,
@@ -984,12 +1000,15 @@ extern "C" {
         fd: c_int,
     ) -> c_int;
 
-    pub fn getutxent() -> *mut utmpx;
-    pub fn getutxid(ut: *const utmpx) -> *mut utmpx;
-    pub fn getutxline(ut: *const utmpx) -> *mut utmpx;
-    pub fn pututxline(ut: *const utmpx) -> *mut utmpx;
-    pub fn setutxent();
-    pub fn endutxent();
+    deprecated_utmpx! {
+        pub fn getutxent() -> *mut utmpx;
+        pub fn getutxid(ut: *const utmpx) -> *mut utmpx;
+        pub fn getutxline(ut: *const utmpx) -> *mut utmpx;
+        pub fn pututxline(ut: *const utmpx) -> *mut utmpx;
+        pub fn setutxent();
+        pub fn endutxent();
+        pub fn utmpxname(file: *const c_char) -> c_int;
+    }
 }

[Ecordonnier]

This is ready to be merged IMO.

[tgross35]

Sorry this fell off my radar, thanks for the changes. LGTM