i128/u128 are not FFI safe

[gnzlbg]

The layout of i128/u128 appears to currently be not fully specified due to: rust-lang/rust#54341 and these types are indeed not safe to use in Rust FFI.

We probably want to guarantee that their layout matches __int128 and similar C language extensions in the platforms that expose them, and to say that their alignment is "implementation-defined" in platforms that do not expose these, probably documenting what it is, at least on Tier-1 platforms like Windows msvc targets.

[elichai]

Would love to see a conversation around this :)
I think FFI is important to the rust ecosystem and having a primitive type that isn't FFI safe is pretty bad

[gnzlbg]

This is blocked on resolving rust-lang/rust#54341 - it doesn't really matter what we specify here if we cannot implement it.

[RalfJung]

Is there anywhere an official list of types that are FFI-safe? Would be nice to have something to point people to.

[gnzlbg]

I don't think such a list exists (might want to look at the improper ctypes lint).

Also, instead of documenting types that are FFI safe (all types are safe for the "Rust" ABI), one should probably document for which types an ABI is well defined (e.g. the "C" ABI is only defined for certain types).

[Diggsey]

all types are safe for the "Rust" ABI

Is that true? What if you pass ownership of a Box<T> in a situation like this:

Static Jemalloc        Static Jemalloc
       |                      |
    Foo.dll <------------> Bar.exe

The Rust ABI doesn't define what allocator to use, so passing ownership of heap allocated types across an ABI boundary is potentially unsafe, even if the ABI does define what the representation should be.

edit:
I know you could do the same thing with C pointers, but ownership is not encoded in the type of a raw pointer, and typically for C APIs you would never actually pass ownership in this way: the caller would be expected to tell the C library to free the pointer rather than trying to do so directly.

[gnzlbg]

Is that true? What if you pass ownership of a Box in a situation like this:

Calling an extern declaration is unsafe. Being able to pass such a function arguments without invoking undefined behavior due to a mismatching calling convention is required but not sufficient for safety. There might be other requirements that you need to prove.

In your particular example, Bar.exe and Foo.dll communicate through extern "Rust" declarations, and you can pass a Box<T> to such a declaration without invoking UB. However, such a declaration might also require you to pass it a Box<T> that has been allocated with the same allocator that, e.g., the dll is using, because it intends to free it with that allocator, so you'd need to prove that as well.

[Lokathor]

(a non-stable implementation detail of Rust on MSVC is that the global allocator is HeapAlloc, using the process heap, so as long as it's not cross-process you can pass allocations between an exe and a dll)

[JakobDegen]

Closing. This is not a T-opsem question, it's mostly tracking a compiler bug