optimization error to security type

[luyikk]

because the current error contains pointers, which makes it unsafe, it is necessary to reposition the error as a safe error, for example, for anyhow.

[luyikk]

If you are just a simple example of dyn error, of course there is no problem, but if it is a complex project, box < dyn error > is rarely used. After the internal pointer is separated from wasm3, it has no meaning and there is no need to save it

发自我的iPhone

------------------ Original ------------------ From: Lukas Wirth @.> Date: Sat,Feb 19,2022 9:27 AM To: wasm3/wasm3-rs @.> Cc: luyikk @.>, Author @.> Subject: Re: [wasm3/wasm3-rs] optimization error to security type (PR #37)

@Veykril commented on this pull request.

In Cargo.toml: > @@ -33,6 +33,7 @@ package = "wasm3-sys" [dev-dependencies] trybuild = "1.0" +anyhow = "1"
There is no reason for us to introduce anyhow here, Result<T, Box<dyn Error>>/Result<T, Box<dyn Error + 'static>> should work just fine. Though in general I would prefer the expects in the examples as they make it more clear what failed and where. Bubbling the errors up to termination loses a lot of information and the examples really don't gain anything from doing "proper" error handling here since they are just usage examples for the API.

In src/error.rs: > /// Error returned by wasm3. #[derive(Copy, Clone, PartialEq, Eq)] -pub struct Wasm3Error(*const cty::c_char); +pub struct Wasm3Error(Wasm3ErrorPtr);
Instead of dancing around between pointer and usize we are better off with just doing unsafe impl Send for Wasm3Error {} and unsafe impl Sync for Wasm3Error {}

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.***>

[luyikk]

Is there any special significance for me to pass the internal pointer up? It will only increase the difficulty of embedding into other projects, errors that are difficult to capture, and unsafe factors. Private use PTR is just to match your logic, but it ensures memory security because users cannot access it. Not send error is a very difficult structure in practical use.

发自我的iPhone

------------------ Original ------------------ From: Lukas Wirth @.> Date: Sat,Feb 19,2022 9:27 AM To: wasm3/wasm3-rs @.> Cc: luyikk @.>, Author @.> Subject: Re: [wasm3/wasm3-rs] optimization error to security type (PR #37)

@Veykril commented on this pull request.

In Cargo.toml: > @@ -33,6 +33,7 @@ package = "wasm3-sys" [dev-dependencies] trybuild = "1.0" +anyhow = "1"
There is no reason for us to introduce anyhow here, Result<T, Box<dyn Error>>/Result<T, Box<dyn Error + 'static>> should work just fine. Though in general I would prefer the expects in the examples as they make it more clear what failed and where. Bubbling the errors up to termination loses a lot of information and the examples really don't gain anything from doing "proper" error handling here since they are just usage examples for the API.

In src/error.rs: > /// Error returned by wasm3. #[derive(Copy, Clone, PartialEq, Eq)] -pub struct Wasm3Error(*const cty::c_char); +pub struct Wasm3Error(Wasm3ErrorPtr);
Instead of dancing around between pointer and usize we are better off with just doing unsafe impl Send for Wasm3Error {} and unsafe impl Sync for Wasm3Error {}

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.***>