Skip to content
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

Check fixed args number for variadic function #4122

Merged
merged 1 commit into from
Jan 29, 2025
Merged

Conversation

tiif
Copy link
Contributor

@tiif tiif commented Jan 4, 2025

This PR added

  • check_shim_variadic to be used by variadic function shims
  • check_min_vararg_count to retrieve varargs array from slice
  • check_fixed_args_count to check if we got expected number of fixed args

cc #4013

@rustbot rustbot added the S-waiting-on-review Status: Waiting for a review to complete label Jan 4, 2025
Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

Please squash

src/helpers.rs Outdated Show resolved Hide resolved
@tiif
Copy link
Contributor Author

tiif commented Jan 7, 2025

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jan 7, 2025
@rustbot

This comment has been minimized.

@tiif
Copy link
Contributor Author

tiif commented Jan 14, 2025

So now there is this weird function definition in this PR

    fn open(
        &mut self,
        args: &[OpTy<'tcx>],
        fixed: &[OpTy<'tcx>; 2],
        _var: &[OpTy<'tcx>],
    ) -> InterpResult<'tcx, Scalar> {

where args is the full function argument, fixed is the fixed args, and _var is var args.

Since we already split fixed and var args through check_shim_variadic before we call this.open, I have tried to not pass args into open, but the problem is if I avoid using args and do this instead

            let [mode] = check_min_arg_count("open(pathname, O_CREAT, ...)", var)?

It will lead to diagnostic like this:

11 |     let _fd = unsafe { libc::open(name_ptr, libc::O_CREAT) }; 
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ incorrect number of arguments for `open(pathname, O_CREAT, ...)`: got 0, expected at least 1

Or maybe we can just ignore the fixed args and var args returned by check_shim_variadic?

@RalfJung
Copy link
Member

It will lead to diagnostic like this:

I would suggest to rename check_min_arg_count to check_min_vararg_count and make the error say something like "not enough variadic arguments for ...".

@tiif
Copy link
Contributor Author

tiif commented Jan 17, 2025

I didn't manage completely replace check_min_arg_count with check_min_vararg_count. There is only left with one check_min_arg_count, which is

fn handle_miri_get_backtrace(
&mut self,
abi: &FnAbi<'tcx, Ty<'tcx>>,
link_name: Symbol,
args: &[OpTy<'tcx>],
dest: &MPlaceTy<'tcx>,
) -> InterpResult<'tcx> {
let this = self.eval_context_mut();
let tcx = this.tcx;
let [flags] = check_min_arg_count("miri_get_backtrace", args)?;

I think as a miri specific extern function, the argument here shouldn't be classified as a vararg?

src/shims/unix/foreign_items.rs Outdated Show resolved Hide resolved
@tiif
Copy link
Contributor Author

tiif commented Jan 17, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jan 17, 2025
@RalfJung
Copy link
Member

I think as a miri specific extern function, the argument here shouldn't be classified as a vararg?

Oh dang.

We have a comment in the docs for this function saying "The flags argument must be 1."
So could you try making a PR that forces the function to have 2 arguments and flags == 1? We recently did the same with miri_resolve_frame, removing support for the old "version 0 protocol"; if we do the same here then we can get rid of this use of check_min_arg_count hopefully. :)

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

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

I left some comments on the first place where you used the new infra; they apply everywhere in the PR.

src/helpers.rs Outdated Show resolved Hide resolved
src/helpers.rs Outdated Show resolved Hide resolved
src/helpers.rs Show resolved Hide resolved
src/shims/unix/android/thread.rs Outdated Show resolved Hide resolved
src/shims/unix/android/thread.rs Outdated Show resolved Hide resolved
src/shims/unix/android/thread.rs Outdated Show resolved Hide resolved
src/shims/unix/fd.rs Outdated Show resolved Hide resolved
@RalfJung
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jan 19, 2025
@tiif
Copy link
Contributor Author

tiif commented Jan 24, 2025

So could you try making a PR that forces the function to have 2 arguments and flags == 1? We recently did the same with miri_resolve_frame, removing support for the old "version 0 protocol"; if we do the same here then we can get rid of this use of check_min_arg_count hopefully. :)

Alright, I can send a follow-up PR after this landed.

src/helpers.rs Outdated Show resolved Hide resolved
@tiif
Copy link
Contributor Author

tiif commented Jan 25, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jan 25, 2025
@RalfJung
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jan 25, 2025
src/helpers.rs Outdated Show resolved Hide resolved
@tiif
Copy link
Contributor Author

tiif commented Jan 28, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jan 28, 2025
@RalfJung
Copy link
Member

Please also squash the PR into a single commit.

@RalfJung
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jan 28, 2025
@tiif
Copy link
Contributor Author

tiif commented Jan 29, 2025

Ooh I accidentally push to github, squash then push, so the change is not visible from Compare.

What have changed:

  • I use /* value does not matter */ 0 for wrong_fixed_arg_count test too since it also has magic number
  • bless the test

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jan 29, 2025
@RalfJung RalfJung enabled auto-merge January 29, 2025 17:15
@RalfJung
Copy link
Member

Looks good :)

@RalfJung RalfJung added this pull request to the merge queue Jan 29, 2025
Merged via the queue into rust-lang:master with commit 489a487 Jan 29, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Waiting for a review to complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants