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

How to wrap types not implementing the Copy trait? #108

Open
gbryant-arm opened this issue May 26, 2020 · 0 comments
Open

How to wrap types not implementing the Copy trait? #108

gbryant-arm opened this issue May 26, 2020 · 0 comments

Comments

@gbryant-arm
Copy link

gbryant-arm commented May 26, 2020

NB: The problem detailed here does not cause any issue in the current state of rust-mbedtls.

bindgen exposes types from the vendor implementation, then some of them are "wrapped" in another type, for instance ssl_config types can be accessed through Config types:

define!(
#[c_ty(ssl_config)]
struct Config<'c>;
const init: fn() -> Self = ssl_config_init;
const drop: fn(&mut Self) = ssl_config_free;
impl<'q> Into<ptr> {}
impl<'q> UnsafeFrom<ptr> {}
);

However this mapping mechanism doesn't seem to work for types that don't implement the Copy trait. The reason for that is the into_inner() function:

pub(crate) fn into_inner(self) -> ::mbedtls_sys::$inner {
let inner = self.inner;
::core::mem::forget(self);
inner

As you can see, self.inner is moved, which is not allowed for types not implementing Copy.

How would you support such types?
What's the rationale behind wrapping the types exposed by bindgen?

mcr pushed a commit to mcr/rust-mbedtls that referenced this issue Aug 10, 2023
This doesn't change the API at all, since it delays any errors until do_call.
Since there was already an `Into<Response> for Error`, and do_call already
had a `.unwrap_or_else(|e| e.into())`, nothing in do_call needed to change.
The only visible effect of this is that code that was previously relying on
`get("/path")` to fetch something from localhost will now get an error. I think
most of those cases would probably actually be accidents, possibly caused
by typos, e.g. `get("example.com/path")` (forgetting the https: prefix).

Fixes fortanix#105
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant