Imported functions with a string or list argument should use a const pointer at ABI level (Rust, C++, C, ?)

[cpetig]

If I take a look into the generated Rust code for the tests/runtime/lists test:

pub fn empty_list_param(a: &[u8]) -> () {
    unsafe {
        let vec0 = a;
        let ptr0 = vec0.as_ptr().cast::<u8>();
        let len0 = vec0.len();
        #[cfg(target_arch = "wasm32")]
        #[link(wasm_import_module = "test:lists/to-test")]
        unsafe extern "C" {
            #[link_name = "empty-list-param"]
            fn wit_import1(_: *mut u8, _: usize);
        }
        #[cfg(not(target_arch = "wasm32"))]
        unsafe extern "C" fn wit_import1(_: *mut u8, _: usize) {
            unreachable!()
        }
        wit_import1(ptr0.cast_mut(), len0);
    }
}

The lowered function could be declared as receiving a const pointer (the host won't free or modify the list. This is also required by the immutable slice argument), this would remove the alarming .cast_mut() call.

(I came to this conclusion while looking into const correctness in the C++ backend)

[alexcrichton]

AFAIK, semantically the meaning of *const T and *mut T is basically the same semantics-wise. The only difference is that the compiler allows mutation of *mut T and doesn't for *const T. This is just a syntactic limitation, however, because you can freely cast between *mut T and *const T and it's not UB to write to a value which at some point was represented with *const T. The UB part is that if a raw pointer started as *const T then it can't be written to, but so long as a raw pointer started as *mut T it can be written to no matter what casts happen in the middle.

That's to say that at least from the Rust perspective i don't think there's any need to change this. I agree it'd be a nice-to-have but the abstraction level for generating the raw type signature here is such that the semantic meaning of the pointers in question have long since been lost.

From a C++ perspective though I'm far less versed in the semantics of const-vs-not pointers so I'm not sure what the rules are there. It might be possible to be more correct about these signatures since the canonical ABI is pretty strict about what is written and what isn't, though.

[cpetig]

My motivation relies on the assumption that you want to minimize unsafe code review effort. (Minimizing the unsafe block's extension/contents to just the call would be a logical next step)

While cast_mut isn't an unsafe function it casts a doubt on whether passing a pointer from an immutable slice to the wit_import1 function causes undefined behavior. I agree that declaring an FFI function which will change (or free) memory as receiving a const pointer is easily done and similarly hard to disprove.

I see value in documenting the (assumed) behavior of this imported function as not changing its inputs, so that this generated code looks less dangerous in a review. Also const correct FFI annotation would amplify the distinction between imports (string arguments are untouched) and exports (string arguments are consumed).

I agree that none of this has any effect on the generated assembly code or the compiler behavior or even the amount of statements requiring unsafe Rust.

[alexcrichton]

That all seems reasonable to me yeah, and if it's easy enough to implement this I don't think there's a reason to avoid it. If a ton of infrastructure is required to get this threaded around I'd say it'd probably not be worth it, but I don't think we're in that bucket.