fuchsia: clean up module by dybucc · Pull Request #5127 · rust-lang/libc

dybucc · 2026-05-31T11:25:53Z

Description

This is a clean-up patch. Changes are concerned with the fuchsia module.

There were lacking definitions. There were records with the wrong alignment. There were types that don't exist upstream. This has been fixed. But there's more stuff to fix.

Testing is pending. This time testing is required. Two supported Fuchsia targets are tier 2. There's no CI job for them.

Sources

Paths are relative to the downloadable SDK. Look under the obj directory. Changes have been made relative to all NEXT releases.

wchar_t is not different across architectures. No specific definition was found. Verifying the current definition was not possible.
nlink_t is not different across architectures.
blksize_t is not different across architectures.
ssizet_t had a wrong definition. Other _t-terminated types had similar issues. Those will not be further repeated in this list.
A number of types did not exist in the SDK. They exist in vendored libc implementations. These are not part of the SDK. They can be found in cs.opensource.google. This includes suffixed offset types. These are omitted from further mention.

sysroot/include/bits/alltypes.h

stat had a mismatched definition.

sysroot/include/bits/stat.h
glob_t had a mismatched definition.

sysroot/include/glob.h

signal.h types often had a mismatched definition. This header file appears later on in this source list. They refer to different paths. They contain different definitions.
Affected types include:
- siginfo_t.
- sigevent.
- sigaction.
There was trouble with constants. SIG_DFL and others are function pointers. They are cast to function pointers from integers. They are sometimes NULL. This is not allowed in Rust. I have wrapped them in Option. They are all None now. They should not all be None. Transmutation from a pointer without provenance to a function pointer is required. This causes compile-time errors.

sysroot/include/signal.h

stat64 doesn't exist.
ipc_perm doesn't exist.
epoll_data doesn't exist. Deprecation lints here keep popping up. I've attempted to silence them. My attempts have been futile.
epoll_event doesn't exist.
ff_effect doesn't exist.
termios2 doesn't exist.
sysinfo doesn't exist.
mq_attr doesn't exist.
sockaddr_nl doesn't exist.
RLIM_SAVED_MAX doesn't exist.
RLIM_SAVED_CUR doesn't exist.
RLIM_INFINITY doesn't exist.
RLIMIT_RTTIME doesn't exist.
RLIMIT_NLIMITS doesn't exist.

There were conditional checks against 32-bit targets. Rust does not support 32-bit Fuchsia targets. The Fuchsia project does not support 32-bit machine word targets.

There was an oddity with pthread.h types. They were defined with a single field. This field sometimes had size equivalent to the sum of upstream fields. This has been replaced with the real fields. This has also fixed some size and alignment mismatches.

This has required changes in macros. An attempt has been made to fit the POSIX definitions. This means expanding static initializers to { 0 }. The new type definitions get all their fields zeroed. Some are made into null pointers. Should they be made into Option::Nones? They are not function pointer fields.

sysroot/include/pthread.h

Macros needed fixing. Their definition did not return a value. But a value was returned upstream. Some types needed small fixes.

sysroot/include/sched.h

m_context had a mismatched definition. Some modules didn't have a definition.
u_context had a mismatched definition. Some modules didn't have a definition.

sysroot/include/bits/signal.h

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

dybucc · 2026-06-09T07:33:01Z

CI actually passes. There seems to be an issue with a glob import that is not used, but this has not
been changed in the patch (it's not even part of it, for that matter.) For some reason, rebasing
onto main with dependabot updates has ended up with a warning across all of my open PRs due to
that one (now apparently unused) import.

tgross35 · 2026-06-19T08:31:22Z

@rustbot blocked
@SnoozeThis wait 2 months -> remove label S-blocked, add label S-waiting-on-review

Like other deprecations, holding off until we can actually give the users an alternative.

SnoozeThis · 2026-06-19T08:32:24Z

(https://snoozeth.is/db3wDy9dFKA) I will wait until Wed, 19 Aug 2026 08:31:22 UTC and then add label S-waiting-on-review and remove label S-blocked.

@rustbot claim.

dybucc · 2026-06-21T17:30:08Z

There's some problems in Fuchsia. Each vendored libc implementation has a different implementation. Sometimes they can be unified. Other times it's not possible. An example of the latter is stat. It resolves to different padding fields.

Should I also expose cfgs for each libc implementation?

dybucc · 2026-06-22T16:01:31Z

@tgross35 The PR has been remade. It now cleans up the fuchsia module.

The description is hopefully clearer. The details of the changes are included there. There should be no need for additional cfgs. Fuchsia has sane defaults and no suffixed types whatsoever. This is only taking into consideration their downloadable SDK. Third party libc implementations they vendor have been ignored.

One deprecation causes CI to fail. Its uses are allowed. That seems insufficient.

Style checks for reasons unknown. The indentation is right. The diagnosed code does not fit the code in my branch. That's likely related to macro expansion issues.

@rustbot ready review

tgross35

There is a lot of orthogonal changes going on here. Could you split it into separate commits to make this more clear? Each section of the PR description could be its own commit, but at a minimum please be sure to separate things like non-functional cleanup and deprecations from anything that's a behavior change. All of this in the same PR is completely fine of course.

(Splitting changes that can stand on their own is good practice in general, see https://www.kernel.org/doc/html/v7.0/process/submitting-patches.html#separate-your-changes for some of the canonical guidelines. Any descriptions/links can also live in the commit messages, it's fine to say "see commit messages for details" in the top post.)

Paths are relative to the downloadable SDK. Look under the obj directory. Changes have been made relative to all NEXT release

In case you haven't come across it, web sources are at https://cs.opensource.google/fuchsia/fuchsia.

Testing is pending. This time testing is required. Two supported Fuchsia targets are tier 2. There's no CI job for them.

It's not required - T2 targets are only "guaranteed to build", which the "verify build" jobs do. We do test a handful of T2 targets, but that's out of convenience rather than requirement.

That said, of course testing everything is ideal. I'll ping the Fuschia maintainers after history gets split.

View changes since this review

tgross35 · 2026-06-22T22:51:40Z

+    // FIXME(i128): __reserved is meant to be an array of `long double`s. That
+    // requires native support for `i128`. This is currently missing.


If you have a source for long double being f128, mind posting it at rust-lang/rust#140417? I would have assumed f64.

Also this comment says i128 but should be f128.

I looked it up in the libc crate. There's a comment in https://github.com/rust-lang/libc/blob/main/src/unix/nto/mod.rs#L799-L810. f128 has equivalent alignment and size constraints to __int128 in gcc.

I read the RFC for f128. It didn't comment on this. I have assumed the comment correct. But it could be wrong.

rustbot · 2026-06-22T23:17:57Z

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

tgross35 · 2026-06-22T23:24:04Z

There's some problems in Fuchsia. Each vendored libc implementation has a different implementation. Sometimes they can be unified. Other times it's not possible. An example of the latter is stat. It resolves to different padding fields.

Should I also expose cfgs for each libc implementation?

Each fuchsia target should only support a single libc. I don't see that listed in https://doc.rust-lang.org/rustc/platform-support/fuchsia.html but perhaps it should be? You could probably open a r-l/r PR updating that if there is a straightforward answer, or an issue if there isn't.

dybucc · 2026-06-23T13:47:02Z

There is a lot of orthogonal changes going on here. Could you split it into separate commits to make this more clear? Each section of the PR description could be its own commit, but at a minimum please be sure to separate things like non-functional cleanup and deprecations from anything that's a behavior change. All of this in the same PR is completely fine of course.

(Splitting changes that can stand on their own is good practice in general, see https://www.kernel.org/doc/html/v7.0/process/submitting-patches.html#separate-your-changes for some of the canonical guidelines. Any descriptions/links can also live in the commit messages, it's fine to say "see commit messages for details" in the top post.)

Paths are relative to the downloadable SDK. Look under the obj directory. Changes have been made relative to all NEXT release

In case you haven't come across it, web sources are at https://cs.opensource.google/fuchsia/fuchsia.

Testing is pending. This time testing is required. Two supported Fuchsia targets are tier 2. There's no CI job for them.

It's not required - T2 targets are only "guaranteed to build", which the "verify build" jobs do. We do test a handful of T2 targets, but that's out of convenience rather than requirement.

That said, of course testing everything is ideal. I'll ping the Fuschia maintainers after history gets split.

View changes since this review

I did come across the source browser. That's were I got confused by the vendored libc implementations. The SDK provides a single set of headers. This makes searches more "coherent."

The testing part was not meant for others. It was a personal reminder. But I understood the testing policy wrong. Just reread "Platform Support" in the rustc book. Thanks.

There are type definitions that do not exist upstream. There are records with wrong fields. There are records with wrong alignment. There are incorrect pollyfils for macros. This patch fixes most of it. But there's stuff I've missed.

There was some infrastructure built for `fd_set`. This was not necessary. This patch simplifies that. It possibley also fixes the definition.

Existing type aliases are equivalent or wrong. This patch mirrors the Fuchsia SDK definitions. There was ambiguity between modules. This has been simplified.

This was pending. Solves a `FIXME`.

They are not shipped in the Fuchsia SDK.

32-bit target conditional compilation was sometimes used. This is unnecessary. Fuchsia does not support 32-bit targets. There were fields with the wrong types. There was some missing padding. This have been fixed.

Architecture-specific types were wrongly defined. This is fixed now.

tgross35 · 2026-06-23T19:25:59Z

Fuchsia maintainers @erickt @Nashenas88 could you clarify which libc headers we should be looking at in the Fuchsia sources?

tgross35

Thank you for splitting it up, this makes things much easier :) Left some notes from a first pass review.

Once the maintainers respond about which libc we should use, please add source links to the commit messages.

View changes since this review

tgross35 · 2026-06-23T19:27:19Z

    pub struct pthread_attr_t {
-        __size: [u64; 7],
+        pub __name: *const c_char,
+        pub __c11: c_int,
+        pub _a_stacksize: crate::size_t,
+        pub _a_guardsize: crate::size_t,
+        pub _a_stackaddr: *mut c_void,
+        pub _a_detach: c_int,
+        pub _a_sched: c_int,
+        pub _a_policy: c_int,
+        pub _a_prio: c_int,
    }


Commit 1: we prefer to keep these opaque. At least the fields should be private, but doesn't the libc just define a repr like this?

tgross35 · 2026-06-23T19:28:40Z

-pub const SIG_DFL: sighandler_t = 0 as sighandler_t;
-pub const SIG_IGN: sighandler_t = 1 as sighandler_t;
-pub const SIG_ERR: sighandler_t = !0 as sighandler_t;
+pub const INT_MIN: c_int = -1 - 0x7fffffff;
+pub const INT_MAX: c_int = 0x7fffffff;
+
+pub const SIG_ERR: Option<sighandler_t> = None;
+pub const SIG_DFL: Option<sighandler_t> = None;
+pub const SIG_IGN: Option<sighandler_t> = None;


Commit 1: can you clarify the sighandler_t change? If sighandler_t is size_t, this doesn't seem right.

tgross35 · 2026-06-23T19:29:06Z

-pub const SIGIOT: c_int = 6;
+pub const SIGIOT: c_int = crate::SIGABRT;

 pub const S_ISUID: mode_t = 0o4000;
 pub const S_ISGID: mode_t = 0o2000;
 pub const S_ISVTX: mode_t = 0o1000;

 pub const IF_NAMESIZE: size_t = 16;
-pub const IFNAMSIZ: size_t = IF_NAMESIZE;
+pub const IFNAMSIZ: size_t = crate::IF_NAMESIZE;


Commit 1: don't these work fine as-is?

tgross35 · 2026-06-23T19:32:07Z


    pub struct fd_set {
-        fds_bits: [c_ulong; FD_SETSIZE as usize / ULONG_SIZE],
+        pub fds_bits: [c_ulong; FD_SETSIZE as usize / 8 / size_of::<c_long>()],


Commit 2: if there hasn't been demand for these fields to be public, make them private.

Commit message has a typo in "It possibley also fixes the definition.", but I'm not sure what that is referring to?

tgross35 · 2026-06-23T19:34:29Z

+    pub union __c_anonymous_sigaction___sa_handler {
+        sa_handler: Option<extern "C" fn(c_int)>,
+        sa_sigaction: Option<extern "C" fn(c_int, *mut siginfo_t, *mut c_void)>,
+    }
+
+    pub struct sigaction {
+        pub __sa_handler: crate::__c_anonymous_sigaction___sa_handler,
+        pub sa_mask: crate::sigset_t,
+        pub sa_flags: c_int,
+        pub sa_restorer: Option<extern "C" fn()>,
+    }


Commit 3: sigaction is broken on all platforms and we should probably fix them all at once, so this commit should be split out. See also:

Creating proper type for sighandler_t using anonymous union on Unix #2107

WIP: Use a more type safe alternative for sigaction types #5076

How should we handle raw function pointers? #4998

tgross35 · 2026-06-23T19:47:53Z

+        pub uc_stack: crate::stack_t,
+        pub uc_mcontext: crate::mcontext_t,
+        pub uc_sigmask: crate::sigset_t,
+        pub __fpregs_mem: [c_ulong; 64],


Commit "fuchsia: fix bits/signal.h types": probably can leave this field private

tgross35 · 2026-06-23T19:49:03Z

+    pub struct __c_anonymous__fpstate__st {
+        pub significand: [c_ushort; 4],
+        pub exponent: c_ushort,
+        pub padding: [c_ushort; 3],
+    }
+
+    pub struct __c_anonymous__fpstate__xmm {
+        element: [c_uint; 4],
+    }
+
+    pub struct _fpstate {


Commit "fuchsia: fix bits/signal.h types": nit, put __c_anonymous_* types after the struct they're a part of, which is what we do most places.

tgross35 · 2026-06-23T19:49:57Z

+    pub struct ucontext_t {
+        uc_flags: c_ulong,
+        uc_link: *mut crate::ucontext_t,
+        uc_stack: crate::stack_t,
+        uc_sigmask: crate::sigset_t,
+        uc_mcontext: crate::mcontext_t,
+    }


Commit "fuchsia: fix bits/signal.h types": Should these fields be public?

tgross35 · 2026-06-23T19:51:09Z

Commit "fuchsia: fix bits/signal.h types": the aarch64 and riscv64 definitions look new, please make sure the commit message is accurate

tgross35 · 2026-06-23T20:00:31Z

Commit "fuchsia: fix bits/signal.h types": the commit message says "Architecture-specific types were wrongly defined. This is fixed now.", and a few other commits do something similar. That doesn't really say what changed - a message that describes the action helps review so we know what to look for, e.g.

Replace the x86_64 mcontext_t opaque field with gregs/fregs, matching upstream definitions.

(https://docs.kernel.org/process/submitting-patches.html#describe-your-changes has some good guidelines here. Not all of it is relevant here of course, but at least the "Describe user-visible impact" and "Describe your changes in imperative mood" bits are great guidelines for all commit messages.)

rustbot · 2026-06-23T22:44:47Z

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.

rustbot added the S-waiting-on-review label May 31, 2026

dybucc force-pushed the fuchsia-bit-width-transition branch 2 times, most recently from 399a0a5 to cc9e351 Compare May 31, 2026 14:59

dybucc mentioned this pull request May 31, 2026

vxworks: add cfg to definition of off64_t and off_t #5129

Open

3 tasks

dybucc force-pushed the fuchsia-bit-width-transition branch from cc9e351 to ddbf270 Compare June 4, 2026 07:05

This comment has been minimized.

Sign in to view

dybucc force-pushed the fuchsia-bit-width-transition branch from ddbf270 to 3783462 Compare June 9, 2026 07:14

This comment has been minimized.

Sign in to view

rustbot added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Jun 9, 2026

dybucc force-pushed the fuchsia-bit-width-transition branch from 3783462 to 53b65df Compare June 15, 2026 15:18

This comment has been minimized.

Sign in to view

rustbot added S-blocked and removed S-waiting-on-review labels Jun 19, 2026

rustbot assigned SnoozeThis Jun 19, 2026

dybucc force-pushed the fuchsia-bit-width-transition branch from 53b65df to b8d548c Compare June 21, 2026 16:24

This comment has been minimized.

Sign in to view

dybucc force-pushed the fuchsia-bit-width-transition branch from 5d7d0ae to 48d5e6a Compare June 22, 2026 06:47

This comment has been minimized.

Sign in to view

dybucc force-pushed the fuchsia-bit-width-transition branch 4 times, most recently from 66e4bed to dd07b99 Compare June 22, 2026 15:09

dybucc changed the title ~~refactor: deprecate off64_t type in Fuchsia~~ fuchsia: clean up module Jun 22, 2026

dybucc force-pushed the fuchsia-bit-width-transition branch 3 times, most recently from 70bef1c to 48d1e3d Compare June 22, 2026 15:57

rustbot added S-waiting-on-review and removed S-blocked labels Jun 22, 2026

tgross35 requested changes Jun 22, 2026

View reviewed changes

rustbot removed the S-waiting-on-review label Jun 22, 2026

rustbot added the S-waiting-on-author label Jun 22, 2026

dybucc force-pushed the fuchsia-bit-width-transition branch from 48d1e3d to 3bd66a6 Compare June 23, 2026 13:46

This comment has been minimized.

Sign in to view

dybucc force-pushed the fuchsia-bit-width-transition branch 5 times, most recently from 2c2cb1d to d615de8 Compare June 23, 2026 16:18

dybucc added 9 commits June 23, 2026 19:29

fuchsia: clean up module

07635ce

There are type definitions that do not exist upstream. There are records with wrong fields. There are records with wrong alignment. There are incorrect pollyfils for macros. This patch fixes most of it. But there's stuff I've missed.

fuchsia: mirror fd_set definition

e542f19

There was some infrastructure built for `fd_set`. This was not necessary. This patch simplifies that. It possibley also fixes the definition.

fuchsia: fix sigaction definition

605a32a

fuchsia: mirror type aliases

cfeb497

Existing type aliases are equivalent or wrong. This patch mirrors the Fuchsia SDK definitions. There was ambiguity between modules. This has been simplified.

fuchsia: add fpos_t

13c6db1

This was pending. Solves a `FIXME`.

fuchsia: deprecate nonexistent types

f97394f

They are not shipped in the Fuchsia SDK.

fuchsia: fix record definitions

5140951

32-bit target conditional compilation was sometimes used. This is unnecessary. Fuchsia does not support 32-bit targets. There were fields with the wrong types. There was some missing padding. This have been fixed.

fuchsia: fix bits/signal.h types

8150008

Architecture-specific types were wrongly defined. This is fixed now.

chore: wip

d1e7799

dybucc force-pushed the fuchsia-bit-width-transition branch from d615de8 to d1e7799 Compare June 23, 2026 17:30

tgross35 reviewed Jun 23, 2026

View reviewed changes

		// FIXME(i128): __reserved is meant to be an array of `long double`s. That
		// requires native support for `i128`. This is currently missing.

Conversation

dybucc commented May 31, 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.

dybucc commented Jun 9, 2026

Uh oh!

This comment has been minimized.

tgross35 commented Jun 19, 2026

Uh oh!

SnoozeThis commented Jun 19, 2026

Uh oh!

This comment has been minimized.

dybucc commented Jun 21, 2026

Uh oh!

This comment has been minimized.

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

Uh oh!

Uh oh!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 22, 2026

Uh oh!

tgross35 commented Jun 22, 2026

Uh oh!

This comment has been minimized.

dybucc commented Jun 23, 2026

Uh oh!

tgross35 commented Jun 23, 2026

Uh oh!

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!

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!

rustbot commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dybucc commented May 31, 2026 •

edited

Loading

dybucc commented Jun 22, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading

dybucc Jun 23, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading