hurd: clean up module by dybucc · Pull Request #5242 · rust-lang/libc

dybucc · 2026-07-02T17:30:03Z

Description

This PR consists of an overall clean up of the GNU Hurd module. It adds proper handling of types and routines when _USE_FILE_OFFSET64 is defined by using the existing gnu_file_offset_bits64 cfg. It also fixes a type definition and more closely mirrors those of upstream.

It also adds a number of future deprecation annotations. These apply only to 64-bit targets on type aliases. They apply to both 64-bit targets and any target with the afore mentioned cfg set in the case of certain records.

Finally, there were some routines that were duplicated in both the unix module and the unix/hurd module. These have ben removed off of the latter. This decision was made because the unix module's definitions already included the right link name redirection for bindings where the actual identifier is the 64-bit suffixed one.

Sources

GNU Hurd glibc fork.

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); especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

tgross35

I just saw the one thing then noticed the links, are you sure that's the most recent source? Per https://cgit.git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=t/sysvshm the branch you're linking hasn't been updated since 2021, and none of the branches at https://cgit.git.savannah.gnu.org/cgit/hurd/glibc.git/refs/heads are any newer.

View changes since this review

tgross35 · 2026-07-04T04:56:53Z

"hurd: remove duplicate routines": LGTM @ 62ccc91

tgross35 · 2026-07-04T05:11:55Z

-        #[cfg(target_pointer_width = "32")]
        pub l_type: c_int,
-        #[cfg(target_pointer_width = "32")]
        pub l_whence: c_int,
-        #[cfg(target_pointer_width = "64")]
-        pub l_type: c_short,
-        #[cfg(target_pointer_width = "64")]
-        pub l_whence: c_short,
-        pub l_start: __off_t,
-        pub l_len: __off_t,
+        pub l_start: off_t,
+        pub l_len: off_t,
        pub l_pid: __pid_t,
    }

    pub struct flock64 {
-        #[cfg(target_pointer_width = "32")]
        pub l_type: c_int,
-        #[cfg(target_pointer_width = "32")]
        pub l_whence: c_int,
-        #[cfg(target_pointer_width = "64")]
-        pub l_type: c_short,
-        #[cfg(target_pointer_width = "64")]
-        pub l_whence: c_short,
-        pub l_start: __off_t,
+        pub l_start: __off64_t,
        pub l_len: __off64_t,
        pub l_pid: __pid_t,


"hurd: use gnu_file_offset_bits64 to expose lfs": Is this accurate? Looking at https://github.com/bminor/glibc/blob/04e750e75b73957cf1c791535a3f4319534a52fc/sysdeps/mach/hurd/bits/types/struct_flock.h and https://github.com/bminor/glibc/blob/04e750e75b73957cf1c791535a3f4319534a52fc/sysdeps/mach/hurd/i386/bits/types/struct_flock.h, it looks like c_short is the right type on non-x86-32.

just reviewed it with the updated glibc sources.

yes, only i386 is to keep the non-posix-compatible int type for l_type/whence

tgross35 · 2026-07-04T05:55:10Z

Yeah - the author of #4127 is the lead Hurd developer as I understand it, and that PR links to the regular glibc sourceware repos. I assume that at some point the deviations were resolved and they just switched to developing upstream.

@rustbot author since there's probably some things to revisit with that in mind.

rustbot · 2026-07-04T05:55:14Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

tgross35 · 2026-07-04T05:57:47Z

"hurd: deprecate lfs types and routines": Note that like the others, I am not comfortable deprecating the time bindings while users don't have a clean-cut solution.

View changes since the review

so, to a first approximation, how would a clean-cut solution look like?

I think that what's at #4805 is the best bet, then we can find+replace these back once everything else is ready.

I'm a bit surprised to see these deprecation warnings indeed, since the Linux port does not have them on its *64 variants.

Claiming The definitions are equivalent when compiling on a 64bit target is wrong: yes on the 64b target they are equivalent, but then the programmer will migrate to the non-64 version and thusly break the 32bit builds unless gnu_file_offset_bits64 is used. So at most the warnings should be enabled only when the programmer did request for gnu_file_offset_bits64, in which case, yes, using the *64 variants is spurious.

but again, better do this on all targets (Linux too notably) altogether rather than just Hurd

those deprecations have now been replaced with comments. they were made before the plan in #4805 had been formulated. now they're just comments tagging some item for future deprecation.

also,

Claiming The definitions are equivalent when compiling on a 64bit target is wrong: yes on the 64b target they are equivalent, but then the programmer will migrate to the non-64 version and thusly break the 32bit builds unless gnu_file_offset_bits64 is used. So at most the warnings should be enabled only when the programmer did request for gnu_file_offset_bits64, in which case, yes, using the *64 variants is spurious.

aren't libc crate users just meant to take care of having the unsuffixed types be used on 64-bit targets, and of having gnu_file_offset_bits64 set on 32-bit targets?

if they're building for multiple targets, surely they must take into account platform differences.

dybucc · 2026-07-08T15:50:46Z

@rustbot ready

tgross35 · 2026-07-09T11:45:59Z

-pub type __squad_type = crate::__int64_t;
-pub type __uquad_type = crate::__uint64_t;
+pub type __squad_type = __int64_t;
+pub type __uquad_type = __uint64_t;


hurd(b32): simplify item paths: LGTM @ acfbb70

View changes since the review

tgross35 · 2026-07-09T11:48:17Z

+    pub struct fpos_t {
+        pub __pos: off_t,
+        pub __state: __mbstate_t,
+    }
+
+    pub struct __mbstate_t {
+        pub __count: c_int,
+        pub __value: __c_anonymous___mbstate_t___value,
+    }


"hurd: fill in definition for fpos_t": let's match linux-gnu and keep these fields private, similarly the union.

libc/src/unix/linux_like/linux/gnu/mod.rs

Line 343 in 328f309

pub struct fpos_t {

View changes since the review

tgross35 · 2026-07-09T11:50:56Z

"hurd: add proper handling of lfs": looks pretty reasonable to me but I'd like the maintainer to ack

View changes since the review

tgross35 · 2026-07-09T11:53:54Z

+cfg_if! {
+    if #[cfg(not(gnu_file_offset_bits64))] {
+        const STAT__SPARE_SIZE: usize = {
+            if size_of::<__fsid_t>() == size_of::<c_int>() {
+                12
+            } else {
+                11
+            }
+        };
+    } else {
+        const STAT__SPARE_SIZE: usize = {
+            if size_of::<__fsid_t>() == size_of::<c_int>() {
+                9
+            } else {
+                8
+            }
+        };
+    }
+}


"hurd: add proper handling of lfs": nit, you can avoid the cfg-if here and instead do ... : usize = { if cfg!(gnu_file_offset_bits64) && size_of::<__fsid_t>() == size_of::<c_int>() { ... } to save a nesting.

Also, looks like there's an extra _ between STAT and SPARE (unless this is in the source?)

View changes since the review

done.

the identifier upstream is simply _SPARE_SIZE. i decided to add another underscore because there's already a "canonical" underscore used for separation between STAT and the actual identifier. considering this is not a public symbol, i decided to opt out of making it match upstream.

tgross35 · 2026-07-09T11:55:16Z

-        pub st_spare: [c_int; 8usize],
+        st_spare: Padding<
+            [c_int; if size_of::<__fsid_t>() == size_of::<c_int>() {
+                9
+            } else {
+                8
+            }],
+        >,


"hurd: add proper handling of lfs": just put this in a const STAT64_SPARE_SIZE like the other, in case we need to reuse that value

View changes since the review

tgross35 · 2026-07-09T11:56:48Z

-        bits: [u32; 32],
-        #[cfg(not(all(target_pointer_width = "32", not(target_arch = "x86_64"))))]
-        bits: [u64; 16],
+        __bits: [__cpu_mask; 1024 / (8 * size_of::<__cpu_mask>())],


"hurd: adjust cpu_set_t definition": use __CPU_SETSIZE and __NCPUBITS intermediates like they do rather than hardcoding, just as nonpublic constants.

View changes since the review

decided i would make them public. __CPU_SETSIZE was already public before this pr so i made __NCPUBITS also public.

tgross35 · 2026-07-09T11:57:17Z

"hurd: remove duplicate definitions": lgtm @ 8b36f4b

View changes since the review

tgross35 · 2026-07-10T02:01:08Z

@rustbot author

rustbot · 2026-07-10T06:17:53Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

dybucc · 2026-07-10T06:31:25Z

@sthibaul would you mind reviewing the changes concerning lfs?

@rustbot label +S-waiting-on-maintainer

sthibaul · 2026-07-10T08:19:48Z

We assume upstream to be the GNU Hurd's fork of glibc hosted at 1.

No, it's not.... The last commit there was 6 years ago...

sthibaul · 2026-07-10T08:32:36Z

        pub st_fstype: c_int,
-        pub st_dev: __fsid_t, /* Actually st_fsid */
-        pub st_ino: __ino_t,
+        pub st_fsid: __fsid_t,


No, we really want st_dev here, to match what the rest of the world expects. st_fsid is the real name in the structure, but st_dev is an alias for it, and that's what people expect. See #3785

View changes since the review

sthibaul · 2026-07-10T08:43:39Z


    pub fn dirfd(dirp: *mut crate::DIR) -> c_int;

-    #[link_name = "__xpg_strerror_r"]


Why dropping this?
See https://sourceware.org/git/?p=glibc.git;a=blob;f=string/string.h;h=743395b3e3b2dd52194b1a6b8c34df4f8b56d8a1;hb=HEAD#l464 and linux does the same (except on musl, which is not ported to GNU/Hurd)

View changes since the review

did that because that one declaration exists when !__USE_GNU ¹, but throughout the libc crate there's definitions affecting the hurd which assume __USE_GNU.

Footnotes

https://sourceware.org/git/?p=glibc.git;a=blob;f=string/string.h;h=743395b3e3b2dd52194b1a6b8c34df4f8b56d8a1;hb=HEAD#l460 ↩

assuming gnu functions are available is not the same as assuming that it's the gnu behavior that is desired.

Really, the linux crate does use the xpg redirection: https://github.com/rust-lang/libc/blob/main/src/unix/linux_like/linux_l4re_shared.rs#L1699 , and thus programs expect the xpg behavior, not the gnu behavior.

i still don't get it. the linux definitions don't affect the hurd but i'm assuming you mean that as an example. why should we provide bindings to the non-gnu version if we have assumed otherwise in other parts of the codebase? granted, the current signature would have to change to that of the gnu version, but that can be readily done as we should be capable of breaking the api on tier 3 targets.

sthibaul · 2026-07-10T08:48:12Z


+    #[cfg_attr(
+        all(gnu_time_bits64, not(gnu_file_offset_bits64)),
+        link_name = "__glob64_time64"


? this doesn't match the conditions of https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/glob.h;h=4c824eb0d30ec557f9c5d5e1d85d823e1a1900c6;hb=HEAD#l158

And note that GNU/Hurd doesn't define __USE_TIME64_REDIRECTS

View changes since the review

fixed. there's one thing to note, though: we recently made it so that our cfgs to handle redirects of time64 and fileoffset64 could not be set separately (though at present we only issue a warning at compile time.) this may conflict with the behavior in upstream glibc where you seem to be capable of opting into one or the other.

sthibaul · 2026-07-10T08:48:29Z

-
+    #[cfg_attr(
+        all(gnu_time_bits64, not(gnu_file_offset_bits64)),
+        link_name = "__globfree64_time64"


ditto

View changes since the review

sthibaul · 2026-07-10T09:02:04Z

+
+    #[cfg_attr(
+        all(gnu_time_bits64, not(gnu_file_offset_bits64)),
+        link_name = "__glob64_time64"


ditto

View changes since the review

sthibaul · 2026-07-10T09:02:16Z

-    pub fn globfree64(pglob: *mut glob64_t);
+    #[cfg_attr(
+        all(gnu_time_bits64, not(gnu_file_offset_bits64)),
+        link_name = "__globfree64_time64"


ditto

View changes since the review

sthibaul · 2026-07-10T09:03:07Z

Thanks for this work!

I'd rather actually test this natively before letting it merged, unfortunately I won't have time to do this before at least tuesday.

sthibaul · 2026-07-10T09:11:53Z

    pub type timezone;
 }

+const STAT__SPARE_SIZE: usize = {


it's a bit sad to make these far from the structure that uses it. Is it not possible to embed the condition in the structure itself? for instance by emitting several st_spare definitions, each conditioned appropriately. We don't really strictly need to define a STAT__SPARE_SIZE condition just to mimick what glibc uses, _SPARE_SIZE is not part of the API.

View changes since the review

those constants weren't public anyway. i've inlined the logic in the structure now.

dybucc · 2026-07-10T11:08:05Z

We assume upstream to be the GNU Hurd's fork of glibc hosted at 1.

No, it's not.... The last commit there was 6 years ago...

i forgot to update the pr description, but i was also told about that little after submitting the patches so the current state should reflect upstream glibc.

add gnu/hurd definition and skip the opaque type definition in the top-level unix module. the definition fits that of [^1]. [^1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/bits/types/__fpos_t.h;h=bb04576651b9097b3027e4299cc30c88f334535f;hb=b5eecf35d91a3b29cff80b731bbc6bcce6863827

add uses of the gnu_file_offset_bits64 cfg to the hurd module. gnu/hurd systems use glibc and that includes both the file offset and time_t feature test macros. this patch ensures the right definition is exposed on 64-unsuffixed types. affected records don't directly use the cfg to define their fields conditionally. they instead use the types not prefixed with two underscores to define their fields. these types are themselves conditionally defined. this avoids cluttering both the type alias definition and the record definition.

modify definition of cpu_set_t to use the same constant expression as used upstream [^1]. this resolves to the same values as before but relies on the conditional definition of the type __cpu_mask is defined in terms of. [^1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/cpu-set.h;h=ddb79cefc2e5d93003f8da84eca6302f99153a22;hb=b5eecf35d91a3b29cff80b731bbc6bcce6863827

remove routines bindings that were already present in the unix module. those in the top-level unix module were already outfit with the corresponding link name redirection under one of gnu_file_offset_bits64 or gnu_time_bits64. they have been preferred over those in the hurd submodule.

add deprecation notices to glob64_t and 64-suffixed routines. the bindings we expose have no difference whatsoever between glob_t and glob64_t. the fields that are different between those two we just have as void pointers.

add deprecation notice to fallocate64 because this routine is only exposed under linux in glibc [^1]. [^1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bits/fcntl-linux.h;h=587b815124318864320973b864899b19466e46b8;hb=HEAD#l450

add comments annotating file offset types and routines whose identifier is 64-suffixed as slated for deprecation and eventual removal. this holds only for 64-bit targets, so the comment adds a "parameter" to the comment that will be found+replaced with a deprecation attribute later on. these types otherwise provide redundant definitions.

rustbot added S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Jul 2, 2026

dybucc force-pushed the hurd-cleanup branch from 6e54ea4 to f16b383 Compare July 3, 2026 05:36

This comment has been minimized.

Sign in to view

tgross35 reviewed Jul 4, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Jul 4, 2026

tgross35 reviewed Jul 4, 2026

View reviewed changes

dybucc force-pushed the hurd-cleanup branch from f16b383 to dd77583 Compare July 8, 2026 08:20

This comment has been minimized.

Sign in to view

dybucc force-pushed the hurd-cleanup branch 2 times, most recently from 6be7cc8 to 7159a66 Compare July 8, 2026 15:48

rustbot added S-waiting-on-review and removed S-waiting-on-author labels Jul 8, 2026

tgross35 reviewed Jul 9, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Jul 10, 2026

hurd(b32): simplify item paths

a94aaa0

dybucc force-pushed the hurd-cleanup branch from 7159a66 to 15c0ee7 Compare July 10, 2026 06:17

rustbot added the S-waiting-on-maintainer label Jul 10, 2026

sthibaul reviewed Jul 10, 2026

View reviewed changes

dybucc force-pushed the hurd-cleanup branch from 15c0ee7 to 0f99e44 Compare July 10, 2026 11:07

dybucc force-pushed the hurd-cleanup branch from 0f99e44 to 0cb1b12 Compare July 10, 2026 13:57

dybucc added 7 commits July 10, 2026 16:30

hurd: deprecate glob64 types and routines

fd26718

add deprecation notices to glob64_t and 64-suffixed routines. the bindings we expose have no difference whatsoever between glob_t and glob64_t. the fields that are different between those two we just have as void pointers.

dybucc force-pushed the hurd-cleanup branch from 0cb1b12 to 0e14b9b Compare July 10, 2026 14:31


		pub fn dirfd(dirp: *mut crate::DIR) -> c_int;

		#[link_name = "__xpg_strerror_r"]

Uh oh!

Conversation

dybucc commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Sources

Checklist

Uh oh!

This comment has been minimized.

This comment has been minimized.

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 commented Jul 4, 2026

Uh oh!

rustbot commented Jul 4, 2026

Uh oh!

tgross35 Jul 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

dybucc commented Jul 8, 2026

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

dybucc commented Jul 2, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading

tgross35 Jul 4, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

tgross35 Jul 9, 2026 •

edited by rustbot

Loading

dybucc commented Jul 10, 2026 •

edited

Loading

sthibaul Jul 10, 2026 •

edited by rustbot

Loading

sthibaul Jul 10, 2026 •

edited by rustbot

Loading

sthibaul Jul 10, 2026 •

edited by rustbot

Loading

sthibaul Jul 10, 2026 •

edited by rustbot

Loading

sthibaul Jul 10, 2026 •

edited by rustbot

Loading

sthibaul Jul 10, 2026 •

edited by rustbot

Loading