nuttx: clean up module by dybucc · Pull Request #5245 · rust-lang/libc

dybucc · 2026-07-03T07:58:53Z

Description

This PR consists of an overall clean up of the NuttX module. It adds missing types, fixes one type definition, replaces equivalent with mirrored definitions (fixed-width types with "variable" C types,) and provides correct support for some build-time configuration options.

The build-time configuration options correspond with CONFIG_SMALL_MEMORY and CONFIG_FS_LARGEFILE. The former enables types with pointer bit width (size_t and ssize_t) to be narrower than required in the target. It is enabled by default in 16-bit machine word targets but can also be enabled in other targets. The latter option enables support for LFS bindings. The default under all targets is to expose 32-bit types and no suffixed 64-bit types. It is only if the above option is set that (1) suffixed types are exposed and (2) unsuffixed types are made 64-bits wide. I have decided against exposing the suffixed types because it's redundant.

Sources

NuttX source repository.
- https://github.com/search?q=repo%3Aapache%2Fnuttx+path%3Aarch%2F**%2F*+%2F%5Cb_ssize_t%5Cb%2F&type=code
- https://github.com/apache/nuttx/blob/master/include/sys/types.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

tgross35 · 2026-07-03T14:02:03Z

 };

+pub type id_t = c_int;
+pub type key_t = u32;


"nuttx: add missing types": Isn't this signed? https://github.com/apache/nuttx/blob/9e467388de0285c1c160681aeafaa9c6b5723ac0/include/sys/types.h#L170

Make sure your links to source are permalinks (available under the triple dots) so we know what things looked like if they change in the future.

View changes since the review

done. noted.

tgross35 · 2026-07-03T14:02:05Z

 pub type dev_t = i32;
 pub type fsblkcnt_t = u64;
+pub type loff_t = off_t;
+pub type cpu_set_t = u32;


"nuttx: add missing types": Is this definition used? I'd prefer to omit it because of the volatile

View changes since the review

it seems like it is upstream ¹. we don't provide any bindings to routines that use it, though.

Footnotes

https://github.com/search?q=repo%3Aapache%2Fnuttx+path%3A**%2F*.h+%2F%5Cbcpu_set_t%5Cb%2F&type=code ↩

In general, avoid adding things without a specific usecase. If somebody needs it and adds it that's fine, but if not then it's kind of opting us into maintenance effort for something that might not even be used.

This also isn't a correct definition anyway, it's volatile.

Agreed. For now, it's best to add things on an as‑needed basis, since the definitions on the NuttX side may change (e.g., ino_t). Don't introduce unused definitions too early.

tgross35 · 2026-07-03T14:02:26Z

 pub type socklen_t = u32;
 pub type speed_t = usize;
 pub type suseconds_t = i32;
+pub type useconds_t = i32;


Isn't this unsigned? https://github.com/apache/nuttx/blob/9e467388de0285c1c160681aeafaa9c6b5723ac0/include/sys/types.h#L259

View changes since the review

you're right. done.

tgross35 · 2026-07-03T14:03:57Z

 pub type tcflag_t = u32;
 pub type clockid_t = i32;
 pub type time_t = i64;
+pub type timer_t = *mut c_void;


Eek far pointers in the definition. Is this actually needed?

View changes since the review

not in our bindings. it is used upstream ¹.

what is it with far pointers? is it inconvenient to test against them because of the segment:offset divide, or is there something else?

Footnotes

https://github.com/search?q=repo%3Aapache%2Fnuttx+path%3A**%2F*.h+%2F%5Cbtimer_t%5Cb%2F&type=code ↩

what is it with far pointers? is it inconvenient to test against them because of the segment:offset divide, or is there something else?

Rust just doesn't support them at all because LLVM support is still in the works, as far as I know.

It looks like this is only relevant on AVR https://github.com/apache/nuttx/blob/cce73da215469a7709cd5ffec5d0ad8d8c98309e/include/nuttx/compiler.h#L471-L545 (though I didn't scan end-to-end) so the definition is technically ok, though same as #5245 (comment) we should avoid adding API with no consumer.

tgross35 · 2026-07-03T14:06:22Z

 pub type key_t = u32;
 pub type nlink_t = u16;
-pub type ino_t = u16;
+pub type ino_t = u32;


"nuttx: fix ino_t definition" this happened just last week apache/nuttx@50377d0, I have no clue what the release/support schedule looks like but we should probably hold off a bit. Or at least hear from the maintainers.

View changes since the review

just pinged the maintainers.

tgross35 · 2026-07-03T14:07:45Z

-pub type wchar_t = i32;
+pub type wchar_t = c_int;


"nuttx: mirror type definitions" Seems fine but where does this one come from?

View changes since the review

pre-defined compiler macros. it's defined as __wchar_type__ ¹, which at least in clang expands to a c int under riscv and to a c unsigned int under arm (both 32- and 64-bit) ². supported rust targets are under either one of these isas.

just made it conditionally compiled when i realized the compiler definitions were different under these two architectures.

Footnotes

https://github.com/search?q=repo%3Aapache%2Fnuttx+%2F%5Cb_wchar_t%5Cb%2F&type=code ↩

https://c.godbolt.org/z/czMY79vsh ↩

tgross35 · 2026-07-03T14:11:02Z

 pub type locale_t = *mut i8;
 pub type mode_t = u32;
 pub type nfds_t = u32;
-pub type off_t = i64;


"nuttx: provide correct lfs support": It looks like we were already supporting CONFIG_FS_LARGEFILE - why the change?

View changes since the review

we were not correctly supporting that configuration. without it enabled, all targets get 32-bit file offset types. with it enabled, they all get 64-bit file offset types.

it would likely come off as a surprise if somebody didn't have CONFIG_FS_LARGEFILE enabled but found that our types are 64-bits either way.

I mean we were only supporting CONFIG_FS_LARGEFILE, right? That's completely fine, every platform has dozens of ways you could configure it that make something break for Rust.

I mean we were only supporting CONFIG_FS_LARGEFILE, right? That's completely fine, every platform has dozens of ways you could configure it that make something break for Rust.

Yes, it is unlikely to support arbitrary configurations of the NuttX ABI on the Rust side, so we must restrict the configuration options that affect fundamental data type definitions and only support the most commonly used combinations.

tgross35 · 2026-07-03T14:13:13Z

 }

+cfg_if! {
+    if #[cfg(nuttx_small_mm)] {


"nuttx: expose cfg for small memory model" similarly, I don't think there is any need to add this - it's extra configuration complexity in libc and has no known users. This would probably have to be a separate target in rustc, anyway.

View changes since the review

Add types that were missing from our bindings to the NuttX interface [^1]. [^1]: https://github.com/apache/nuttx/blob/cce73da215469a7709cd5ffec5d0ad8d8c98309e/include/sys/types.h#L170

Fix `ino_t` definition to fit that of [^1]. [^1]: https://github.com/apache/nuttx/blob/master/include/sys/types.h#L163

fix signedness of wchar_t under arm and aarch64. this was not correctly handled as this type will likely be defined in terms of predefined compiler macros [^1]. these macros expand to different types on our currently supported nuttx targets. they are only signed integers under riscv [^2]. [^1]: https://github.com/search?q=repo%3Aapache%2Fnuttx+%2F%5Cb_wchar_t%5Cb%2F&type=code [^2]: https://c.godbolt.org/z/czMY79vsh

Use `gnu_file_offset_bits64` `cfg` to export LFS bindings. NuttX follows that "64"-suffixed symbols are exposed only if large file support is enabled [^1] [^2]. We choose not to expose those because it's redundant. Otherwise, the existing `cfg` serves the same purpose as upstream's `CONFIG_FS_LARGEFILE` build option. [^1]: https://github.com/apache/nuttx/blob/master/include/sys/types.h#L88-L95 [^2]: https://github.com/apache/nuttx/blob/master/include/sys/types.h#L199-L226

rustbot · 2026-07-07T15:19:06Z

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-07T15:20:11Z

@no1wudi, you think we can already have an ino_t definition that matches upstream? there was a recent change there and this pr includes it, but maybe that's a bit too early to make changes.

@rustbot ready

no1wudi · 2026-07-08T00:57:24Z

+// types are themselves 64-bits wide. We choose to expose ony the latter.
+cfg_if! {
+    if #[cfg(gnu_file_offset_bits64)] {
+        pub type fsblkcnt_t = u64;


There are too many configuration options inside Nuttx; it would be better to only support specific projects. For example, FS_LARGEFS must be enabled; otherwise, compilation becomes overly difficult.

View changes since the review

no1wudi · 2026-07-08T01:00:31Z

 pub type dev_t = i32;
 pub type fsblkcnt_t = u64;
+pub type loff_t = off_t;
+pub type cpu_set_t = u32;


Agreed. For now, it's best to add things on an as‑needed basis, since the definitions on the NuttX side may change (e.g., ino_t). Don't introduce unused definitions too early.

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

tgross35 reviewed Jul 3, 2026

View reviewed changes

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

dybucc added 5 commits July 7, 2026 15:59

nuttx: add missing types

7561973

Add types that were missing from our bindings to the NuttX interface [^1]. [^1]: https://github.com/apache/nuttx/blob/cce73da215469a7709cd5ffec5d0ad8d8c98309e/include/sys/types.h#L170

nuttx: fix ino_t definition

140e7ab

Fix `ino_t` definition to fit that of [^1]. [^1]: https://github.com/apache/nuttx/blob/master/include/sys/types.h#L163

nuttx: mirror type definitions

f46c3da

dybucc force-pushed the nuttx-cleanup branch from 4a84e5c to 6b62a27 Compare July 7, 2026 15:19

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

no1wudi suggested changes Jul 8, 2026

View reviewed changes

Uh oh!

Conversation

dybucc commented Jul 3, 2026

Description

Sources

Checklist

Uh oh!

tgross35 Jul 3, 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 3, 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

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 3, 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 3, 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

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 3, 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 3, 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

Footnotes

Uh oh!

tgross35 Jul 3, 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!

tgross35 Jul 3, 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!

rustbot commented Jul 7, 2026

Uh oh!

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

Uh oh!

Uh oh!

no1wudi Jul 8, 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!

Reviewers

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

tgross35 Jul 3, 2026 •

edited by rustbot

Loading

dybucc commented Jul 7, 2026 •

edited

Loading

no1wudi Jul 8, 2026 •

edited by rustbot

Loading