Open mayabyte opened 4 years ago
Yes, this is what opaque_type
causes when used on this kind of stuff... That being said, it seems to me it's a rust bug to complain that *const root::example_type
is not FFI-safe...
That being said, it seems to me it's a rust bug to complain that
*const root::example_type
is not FFI-safe...
Out of curiosity, why is this mapping happening? Does this array represent multiple pointers (context, parameters and return value?) or what does it mean semantically?
Out of curiosity, why is this mapping happening?
This related issue https://github.com/rust-lang/rust-bindgen/issues/2071#issuecomment-882329820 states that basically the example_type
should not be translated by bindgen, but since bindgen does it anyway, the user should blocklist it manually.
header.hpp
:bindgen
invocation:Output binding:
With just a plain
typedef
like this all is well, but in many situationsbindgen
also needs to use this type (possibly indirectly) in anextern "C" {...}
block, resulting in warnings like this:While not strictly an error, it makes me uneasy that function pointers may or may not be interpreted correctly between the C++ library I need to use and my own code.
Is there a way to get
bindgen
to generate, say,&[u64; 6usize]
or something forstd::function
s instead? Is this intended behavior or unexpected?I have a feeling this could be related to the use of
.opaque_type("std::.*")
, but whitelistingstd::function
doesn't seem to change anything and I'd greatly prefer not to generate bindings for all ofstd
.