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 •
edited
Loading

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.

Sign in to view
@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.

Sign in to view
@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.

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

tgross35 commented Jun 19, 2026

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

SnoozeThis commented Jun 19, 2026

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

rustbot commented Jun 21, 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.

@dybucc
vxworks: gate off64_t behind cfg
0b3f97d 
VxWorks exposes a different bit width for `off64_t`. This will depend on
whether the program is a real-time-process. `off_t` will be 64-bits if
it is.

`off64_t` only exists when compiling kernels. `off_t` may then be
32-bits or 64-bits wide. This will depend on whether the target follows
LP64. `off64_t` is then 64-bits wide.

Two routines were removed. They were explicitly excluded from the
shipped SDK.
@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 •
edited
Loading

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

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

Reviewers

No reviews

Assignees

@SnoozeThis SnoozeThis

Labels

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

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@dybucc @rustbot @tgross35 @SnoozeThis