Skip to content

Conversation

@japaric
Copy link

@japaric japaric commented Apr 14, 2019

Please read #111 first, if you haven't already.

Rendered discussion document

## Questions

- Can this program be misoptimized given that the compiler has *no* information
about `INTERRUPT0` and `INTERRUPT1` executing "cooperatively"?
Copy link
Member

@RalfJung RalfJung May 5, 2019

Choose a reason for hiding this comment

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

The crucial aliasing point here is: the moment INTERRUPT1 starts executing, any previously created pointer such as everything done in INTERRUPT0 gets invalidated.

So, safety relies on the assumption that the safe code cannot somehow leak the &'static mut that it got -- for example, through a static X: RefCell<Option<&'static mut u128>> or so. I assume that is possible for safe code even on BEAM, so this would not be a safe abstraction. But if you change it as follows, I think this hole is plugged:

#[no_mangle] unsafe fn INTERRUPT1() { let x: &mut u128 = unsafe { &mut X }; inner(x); // Crucially, inner is generic in the lifetime and hence // cannot leak the reference. fn inner(x: &mut u128) { // .. any safe code .. } }

Besides this point, I agree that the program is fine as far as Stacked Borrows is concerned. I can only hope LLVM agrees with that. ;) The compiler cannot know that the functions cooperate, but when it doubt it has to assume that they do.

@RalfJung
Copy link
Member

Closing due to inactivity, see #169 for tracking.

@RalfJung RalfJung closed this Jul 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants