FFI and provenance

[joshlf]

This is related to #466

Consider an extern function which returns a pointer:

#[repr(C)]
struct Foo { ... }

extern "C" fn new_foo() -> *Foo;

Does new_foo return a pointer with provenance for its entire referent? In other words, does new_foo "introduce" new memory into the Rust AM (assuming that it isn't returning a pointer to memory which is already in the AM)?

[RalfJung]

new_foo needs to come with a story written in Rust and that story then also defines what the provenance of the returned point will be.

[joshlf]

What would be an example of a story that would be valid for something like:

• mmap
• A pointer that comes from userspace (when the Rust code in question is implementing a kernel)

[RalfJung]

A pointer that comes from userspace (when the Rust code in question is implementing a kernel)

That's such a big discussion it has its own thread: #607.

mmap

Basically, mmap is malloc and munmap is free. Adding more pages to the end of the allocation is something that LLVM supports now but we currently don't bless it in Rust -- the biggest difficulty is probably how and where to even document this. munmap of part of an allocation, and adding more pages before the beginning of an allocation, and allocations "with holes", are all in conflict with optimizations LLVM is allowed to perform, so before a story can be written for those someone needs to figure out whether LLVM actually does those optimizations, and then either negotiate about removing them or adding documentation promising that such optimizations will also not be added in the future. Alternatively, #606 could also provide a way for dealing with this.