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

It is documented nowhere that primitives and thin pointers are FFI-safe #31227

Closed
arielb1 opened this issue Jan 26, 2016 · 8 comments
Closed
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools

Comments

@arielb1
Copy link
Contributor

arielb1 commented Jan 26, 2016

In particular, only thin pointers are FFI safe, and not fat pointers. This is somewhat confusing.

rel: https://doc.rust-lang.org/nightly/nomicon/data.html

cc @gankro

@arielb1
Copy link
Contributor Author

arielb1 commented Jan 26, 2016

cc #30382

@Gankra
Copy link
Contributor

Gankra commented Jan 27, 2016

Yeah FFI stuff has been in a weird limbo iirc. I don't really touch on it in the nomicon, and TRPL's bits on it are being redone.

@briansmith
Copy link
Contributor

Also, it isn't documented (AFAICT) that one can pass a reference or mutable reference where an extern "C" function takes a const pointer or non-const pointer.

@ustulation
Copy link

ustulation commented Jan 26, 2017

I replied to this over here but realised later the issue was closed - so am putting it here again in an open issue hoping that's fine.

There's a lint for this, at least when declaring extern functions

I checked that and it works, i was wondering is there anything for the reverse - for e.g.: this.

The other function find does not give any warning. Though I understand that all it says is it follow C calling convention and no name-mangling none of which might warrant the parameter type warning, it is usually intended to be called form another language (with C compatibility) so should generate a warning in this case too ? Passing a callback from C for instance will be Undefined Behavior in this case. I was also stung by this:

#[no_mangle]
pub unsafe extern "C" fn(cb: extern "C" fn([u8; 32])) { // WRONG - should be fn(*const [u8; 32])
    let arr = [8u8; 32];
    cb(arr); // WRONG - should be &arr
}

Of-course looking back it was a stupid mistake - but i had subconciously assumed array would decay into a ptr like in C when callback was invoked. All my tests passed as they were written in rust. Only when interfacing with C and running into occassional seg-faults that i realised the mistake. If there was a warning or some language feature to mark that this function is not only for C ABI compatibility but also strictly for a call from C (like what extern "C" { } block does) it would be helpful.

Same with repr(C) - there is no warning for completely non-C struct having this attribute - i understand the reasoning from the docs for this but again if there is some lint/attribute to mark strict C only conformance then that would be great - as you know it's pita to debug C errors otherwise :(

@steveklabnik steveklabnik added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Mar 10, 2017
@steveklabnik
Copy link
Member

nominating for next docs meeting

@QuietMisdreavus
Copy link
Member

Thanks to rust-lang-nursery/nomicon#21, FFI documentation now has a proper home in the nomicon! If you want to tackle this issue, please add the documentation there.

@steveklabnik
Copy link
Member

Yup; that repo is the appropriate place now. Closing!

@QuietMisdreavus
Copy link
Member

I've opened rust-lang-nursery/nomicon#23 to port this issue over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools
Projects
None yet
Development

No branches or pull requests

6 participants