Skip to content

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

Open
dybucc wants to merge 1 commit into
rust-lang:mainfrom
dybucc:vxworks-bit-width-transition
Open

vxworks: add cfg to definition of off64_t and off_t#5129
dybucc wants to merge 1 commit into
rust-lang:mainfrom
dybucc:vxworks-bit-width-transition

Conversation

@dybucc

@dybucc dybucc commented May 31, 2026

Copy link
Copy Markdown
Contributor

Description

This PR improves the definition of off_t. This applies to targets whose operating system is VxWorks.

The libc crate defines off_t as a c_longlong. This is only correct in programs compiled as RTPs. Programs compiled as VxWorks kernels are different. They expose off_t as a c_long.

The off64_ type is not present in RTP processes.

Automatic detection of this does not seem possible in Rust. A specific flag is issued to gcc to expose the feature test macro. This patch adds an equivalent cfg. The crate user must manually set it.

Two redundant routines were removed. These are explicitly out of the shipped SDK. It seems like the libc crate had polyfills set up. These would always return an error value.

Sources

  • Lines 23-33 of file sysroot/usr/h/public/base/b_off_t.h. This was found in the VxWorks downloadable SDK for QEMU x86_64.
  • File usr/3pp/develop/usr/include/python3.9/pyconfig.h. This was found in the same as SDK as quoted above. This defines certain included features. pread and pwrite are not defined.

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 dybucc force-pushed the vxworks-bit-width-transition branch 2 times, most recently from fb9aeb7 to 675bad7 Compare June 4, 2026 07:05
@rustbot

This comment has been minimized.

@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from 675bad7 to 3d55d66 Compare June 9, 2026 07:14
@rustbot

This comment has been minimized.

@dybucc

dybucc commented Jun 9, 2026

Copy link
Copy Markdown
Contributor Author

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.

@rustbot rustbot added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Jun 9, 2026
@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from 3d55d66 to 04a0d17 Compare June 15, 2026 15:16
@rustbot

This comment has been minimized.

@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from 04a0d17 to 6b96768 Compare June 15, 2026 15:34
@tgross35

Copy link
Copy Markdown
Contributor

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

Holding off until there is a good alternative to off64_t

@SnoozeThis

Copy link
Copy Markdown

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

@rustbot claim.

@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from 6b96768 to 1d99a12 Compare June 21, 2026 15:20
@rustbot

This comment has been minimized.

@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from 1d99a12 to 0b3f97d Compare June 21, 2026 15:33
@dybucc dybucc changed the title refactor: deprecate off64_t in VxWorks vxworks: add cfg to definition of off64_t and off_t Jun 21, 2026
@dybucc

dybucc commented Jun 21, 2026

Copy link
Copy Markdown
Contributor Author

@tgross35 The PR has been updated. I don't think I can find a better solution. Both off_t and off64_t are defined in VxWorks. The best I can do is to gate them.

off_t will always be defined. Its bit width may be 64-bits in RTPs. Its bit width may be 32-bits or 64-bits in kernel programs. off64_t will only be defined in kernel programs. off64_t will always be 64-bits wide.

@rustbot ready review

Comment thread src/vxworks/mod.rs Outdated
Comment on lines +60 to +67
pub type off_t = c_longlong;
pub type off64_t = off_t;
cfg_if! {
if #[cfg(vxworks_rtp)] {
pub type off_t = c_longlong;
} else {
pub type off_t = c_long;
pub type off64_t = c_longlong;
}
}

@tgross35 tgross35 Jun 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the existing definitions seem to match rtp, could there be an assumption that vxworks builds are always targeting RTPs rather than kernel? I don't see it documented here https://doc.rust-lang.org/rustc/platform-support/vxworks.html but that's usually a reasonable assumption for most targets.

Cc maintainers @biabbas @hax0kartik

View changes since the review

@hax0kartik

Copy link
Copy Markdown
Contributor

hi, thanks for the PR but we do not support rust in VxWorks kernel mode. I’m going to reject this change as the platform maintainer.

@tgross35

Copy link
Copy Markdown
Contributor

Ack, thanks for taking a look!

@dybucc this can probably be repurposed as a docs PR to help others in the future. We don't really have anything like this yet but I think the new module would be a reasonable place to keep platform-specific docs, https://github.com/rust-lang/libc/blob/main/src/new/vxworks/mod.rs.

@rustbot author
@SnoozeThis /cancel

@rustbot

rustbot commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

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

@SnoozeThis

Copy link
Copy Markdown

Snooze cancelled.

@rustbot release-assignment.

@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from 0b3f97d to ef3abc5 Compare June 23, 2026 13:30
@rustbot

rustbot commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

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.

VxWorks compiles to RTPs and kernels. RTPs do not expose `off64_t`. Rust
can not be used with VxWorks kernels. `off64_t` should not be part of
the crate.

Two polyfill routines were removed. They were stubs for errors. They did
not set up `errno` either.
@dybucc dybucc force-pushed the vxworks-bit-width-transition branch from ef3abc5 to df963e7 Compare June 23, 2026 13:35
@dybucc

dybucc commented Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

Ack, thanks for taking a look!

@dybucc this can probably be repurposed as a docs PR to help others in the future. We don't really have anything like this yet but I think the new module would be a reasonable place to keep platform-specific docs, https://github.com/rust-lang/libc/blob/main/src/new/vxworks/mod.rs.

@rustbot author @SnoozeThis /cancel

That's done now. The PR documents that. Kernel symbols are deprecated. This includes off64_t. This is not exposed in RTPs.

@rustbot ready

Comment thread src/vxworks/mod.rs
Comment on lines +64 to +65
note = "Use `off_t` instead. This type does not exist. It's only present in VxWorks kernels. \
Those are unsupported in Rust."

@tgross35 tgross35 Jun 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simplify to something like "Kernel-mode definitions are not supported in VxWorks. Use off_t instead.". Otherwise LGTM.

View changes since the review

Comment thread src/new/vxworks/mod.rs
Comment on lines +3 to +5
//! VxWorks allows compiling different types of programs. Exposed bindings are
//! with respect to RTPs. VxWorks kernel interfaces are not exposed. `off_t` is
//! an example of this. It's a `c_long` in kernels. It's a `c_longlong` in RTPs.

@tgross35 tgross35 Jun 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

//! VxWorks allows compiling different types of programs but `libc` only supports
//! RTPs (real-time processes), not kernel interfaces. Bindings should match RTP
//! definitions when there is a discrepancy.

Dropping the concrete example

View changes since the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants