Skip to content

limit impls of VaArgSafe to just types that are actually safe #141341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 22, 2025

Conversation

folkertdev
Copy link
Contributor

tracking issue: #44930

Retrieving 8- or 16-bit integer arguments from a VaList is not safe, because such types are subject to upcasting. See #61275 (comment) for more detail.

This PR also makes the instances of VaArgSafe visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of VaArgSafe, which would almost certainly cause UB.

r? @workingjubilee

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 21, 2025
/// Trait which permits the allowed types to be used with [super::VaListImpl::arg].
pub unsafe trait VaArgSafe: sealed::Sealed {}

unsafe impl VaArgSafe for i32 {}
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a comment capturing a short form of the justification here? like "variable arguments must be promoted to at least c_int, but Rust doesn't implicitly promote".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a # Safety section to the trait with some extra details, and comments for the (deliberately) missing implementations. Hopefully that is sufficiently clear.

@rust-log-analyzer

This comment has been minimized.

8 and 16-bit integers are subject to upcasting in C, and hence are not reliably safe. users should perform their own casting and deal with the consequences
@folkertdev folkertdev force-pushed the limit-VaArgSafe-impls branch from bede725 to d8a22a2 Compare May 21, 2025 13:36
@rustbot
Copy link
Collaborator

rustbot commented May 21, 2025

This PR modifies run-make tests.

cc @jieyouxu

@rustbot rustbot added the A-run-make Area: port run-make Makefiles to rmake.rs label May 21, 2025
@workingjubilee
Copy link
Member

cool.

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented May 21, 2025

📌 Commit d8a22a2 has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request May 21, 2025
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#140526 (docs: Specify that common sort functions sort in an ascending direction)
 - rust-lang#141230 (std: fix doctest and explain for `as_slices` and `as_mut_slices` in `VecDeque`)
 - rust-lang#141341 (limit impls of `VaArgSafe` to just types that are actually safe)
 - rust-lang#141347 (incorrectly prefer builtin `dyn` impls :3)
 - rust-lang#141351 (Move -Zcrate-attr injection to just after crate root parsing)
 - rust-lang#141356 (lower bodies' params to thir before the body's value)
 - rust-lang#141357 (`unpretty=thir-tree`: don't require the final expr to be the body's value)
 - rust-lang#141363 (Document why we allow escaping bound vars in LTA norm)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit b9c6b33 into rust-lang:master May 22, 2025
6 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 22, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 22, 2025
Rollup merge of rust-lang#141341 - folkertdev:limit-VaArgSafe-impls, r=workingjubilee

limit impls of `VaArgSafe` to just types that are actually safe

tracking issue: rust-lang#44930

Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See rust-lang#61275 (comment) for more detail.

This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB.

r? `@workingjubilee`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants