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

What are the contents of the return place upon unwinding? #468

Closed
RalfJung opened this issue Oct 8, 2023 · 2 comments
Closed

What are the contents of the return place upon unwinding? #468

RalfJung opened this issue Oct 8, 2023 · 2 comments

Comments

@RalfJung
Copy link
Member

RalfJung commented Oct 8, 2023

This question came up here. When a function is called, performs some writes to its return local, and then unwinds -- what do we guarantee about the contents of the return place (i.e., the place given by the caller to store the return value in)?

The semantics currently implemented in Miri are: when the function is called, the return place is de-initialized. The function locally creates a fresh place to back its return local. Writes to the return local only affect that temporary place. Upon unwinding, no copying of a return value happens, so the return place remains fully uninitialized.

Those seem like reasonable semantics. We effectively do not guarantee anything about that place when unwinding happened. Any objections/discussion or shall we move to FCP directly?

@bjorn3
Copy link
Member

bjorn3 commented Oct 8, 2023

I agree that the semantics implemented in miri are reasonable. I don't think it is observable in the user facing language though, only in MIR.

bors added a commit to rust-lang/miri that referenced this issue Oct 9, 2023
ensure RET assignments do not get propagated on unwinding

Mostly this adds a test for rust-lang/unsafe-code-guidelines#468, and then also some other related tests I thought of while writing that test.
@RalfJung
Copy link
Member Author

RalfJung commented Oct 9, 2023

rust-lang/miri#3114 adds a test in Miri.

I'll close this then as "not controversial" and "does not even apply to surface language".

@RalfJung RalfJung closed this as completed Oct 9, 2023
RalfJung pushed a commit to RalfJung/rust that referenced this issue Oct 21, 2023
ensure RET assignments do not get propagated on unwinding

Mostly this adds a test for rust-lang/unsafe-code-guidelines#468, and then also some other related tests I thought of while writing that test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants