Add opaque structs to TRPL:FFI#27542
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
It would be nice if you mentioned the C headers/prototypes that are being bound here, e.g. struct Foo; /* Foo is a structure, but its contents are not part of the public interface */
struct Bar;
void foo(struct Foo *arg);
void bar(struct Bar *arg);so that people know what an opaque struct looks like in C. This is something you don't really have to pay attention to a library user, so the terminology might be unclear (especially the distinction from the C++ or nonstandard C syntax Which brings up one quibble I have here: if the original C API actually does use opaque structs, instead of void pointers, then C users of that API are type-safe. C compilers will warn you about casts between pointers of different types, unless I guess you were envisioning binding a C API that uses |
src/doc/trpl/ffi.md
Outdated
There was a problem hiding this comment.
This seems to imply that in order to create an opaque type that we can't instantiate, we must not annotate it with repr(C), which is a bit confusing since #[repr(C)] enum Foo {} doesn't compile. Maybe you want something more like
"By using an enum with no variants, we create an opaque type that we can't instantiate. (Note that we don't annotate it with repr(C), which isn't valid syntax for enums.)"
There was a problem hiding this comment.
This is actually one of the special cases where #[repr(C)] on an enum is invalid, but there are cases where that's useful:
#[repr(C)]
enum Foo {
Bar,
Baz = 3,
Foobar,
}I believe you just need to have at least 2 variants and none of the variants can have a data payload.
There was a problem hiding this comment.
yeah, i'll just take that bit out, as it's more distracting
|
Try this new version on for size. |
There was a problem hiding this comment.
Unclear what "this" is -- did it get lost in refactoring? Did you want to say that foo and bar take different types of arguments?
Fixes #27303