search for: into_raw

...it will not get freed. If you do not explicly write lifetime here, the pointer will have static lifetime. https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak I think It is too long. But I think there is no more 'correct' lifetime than 'a. Actually, I wanted to use Weak::into_raw there. However, it is nightly-feature now. > if you do Box::into_raw instead of Box::leak, you get a *mut right away > that you do not need to cast twice, I believe. Otherwise it should be the same, > I think. If you use Box::into_raw, you must make sure that they are freed by yourself...

...:Arc<C>) }; + let callback = sync::Arc::clone(&callback_ptr); + callback(event, eh, buf, array) + } + let callback = sync::Arc::<C>::new(callback); + let event_bitmask = events_to_bitmask(events); + + let eh = { + // Weak::into_raw is nightly. + // In order to make sure that callback is freed when handle is freed, + // lifetime is explicitly declared. + let ptr: &'a sync::Arc<C> = Box::leak(Box::new(callback.clone())); + unsafe { + guestfs_set_event_call...

...let callback = sync::Arc::clone(&callback_ptr); >+ callback(event, eh, buf, array) >+ } >+ let callback = sync::Arc::<C>::new(callback); >+ let event_bitmask = events_to_bitmask(events); >+ >+ let eh = { >+ // Weak::into_raw is nightly. >+ // In order to make sure that callback is freed when handle is freed, >+ // lifetime is explicitly declared. >+ let ptr: &'a sync::Arc<C> = Box::leak(Box::new(callback.clone())); So this has a lifetime same as the whole handle?...

...ing unless we put some dummy + // fields here. In a real implementation you would put per-handle + // data here as required. + _not_used: i32, +} + +extern fn ramdisk_open (_readonly: c_int) -> *mut c_void { + let h = Handle {_not_used: 0}; + let h = Box::new(h); + return Box::into_raw(h) as *mut c_void; +} + +extern fn ramdisk_close (h: *mut c_void) { + let h = unsafe { Box::from_raw(h as *mut Handle) }; + drop (h); +} + +extern fn ramdisk_get_size (_h: *mut c_void) -> int64_t { + return DISK.lock().unwrap().capacity() as int64_t; +} + +extern fn ramdisk_pread (_h: *...

This adds very rough support for writing nbdkit plugins in Rust. This is not very idiomatic -- essentially we're handling the direct C calls from nbdkit in Rust. We have to use ‘unsafe’ in a few places because there's no way to tell the Rust code that nbdkit satisfies guarantees (eg. around thread safety, always returning leaked pointers back to the close function, always doing bounds

...} + + // Because trait pointer is fat pointer, in order to pass it to API, + // double Box is used. + let callback: Box<Box<dyn Fn(guestfs::Event, EventHandle, &[u8], &[u64]) + 'a>> = + Box::new(Box::new(callback)); + let ptr = Box::into_raw(callback); + let callback = unsafe { Box::from_raw(ptr) }; + let event_bitmask = events_to_bitmask(events); + + let eh = { + unsafe { + guestfs_set_event_callback( + self.g, + trampoline::<C>, +...

...(e.g. CString, *const c_char) + * RawSOptArgs: Each field has raw pointers or integer values + * + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs + * + * Note: direct translation from SOptArgs to RawSOptArgs will cause a memory + * management problem. Using into_raw/from_raw, this problem can be avoided, + * but it is complex to handle freeing memories manually in Rust because of + * panic/?/etc. + *) + (* generate structs for optional arguments *) List.iter ( fun ({ name = name; shortdesc = shortdesc; style = (ret, args, optargs) }...

I fixed based on comments. I'll send these two patches to this mailing list. - Fix Handle -> Handle<'a> - Add events Regards, Hiroyuki 2019年8月1日(木) 0:01 Pino Toscano <ptoscano@redhat.com>: > Hi Hiroyuki, > > On Tuesday, 30 July 2019 07:51:37 CEST Hiroyuki Katsura wrote: > > This patch includes: > > > > - Event callback handlers > > -

Patch 9 is a kind of dumping ground of all kinds of stuff. It may be better to spend some time with git rebase -i trying to work this into more coherent patches. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live

...(e.g. CString, *const c_char) + * RawSOptArgs: Each field has raw pointers or integer values + * + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs + * + * Note: direct translation from SOptArgs to RawSOptArgs will cause a memory + * management problem. Using into_raw/from_raw, this problem can be avoided, + * but it is complex to handle freeing memories manually in Rust because of + * panic/?/etc. + *) (* generate structs for optional arguments *) List.iter ( @@ -383,27 +434,75 @@ impl UUID { pr "\n"; pr "/* Option...

...(e.g. CString, *const c_char) + * RawSOptArgs: Each field has raw pointers or integer values + * + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs + * + * Note: direct translation from SOptArgs to RawSOptArgs will cause a memory + * management problem. Using into_raw/from_raw, this problem can be avoided, + * but it is complex to handle freeing memories manually in Rust because of + * panic/?/etc. + *) + (* generate structs for optional arguments *) + List.iter ( + fun ({ name = name; shortdesc = shortdesc; + style = (ret, args, optargs) })...

...+ * RawSOptArgs: Each field has raw pointers or integer values > + * > + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs > + * > + * Note: direct translation from SOptArgs to RawSOptArgs will cause a > memory > + * management problem. Using into_raw/from_raw, this problem can be > avoided, > + * but it is complex to handle freeing memories manually in Rust > because of > + * panic/?/etc. > + *) > + (* generate structs for optional arguments *) > + List.iter ( > + fun ({ name = name; shortdesc = shortdesc; &gt...

...(e.g. CString, *const c_char) + * RawSOptArgs: Each field has raw pointers or integer values + * + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs + * + * Note: direct translation from SOptArgs to RawSOptArgs will cause a memory + * management problem. Using into_raw/from_raw, this problem can be avoided, + * but it is complex to handle freeing memories manually in Rust because of + * panic/?/etc. + *) + (* generate structs for optional arguments *) + List.iter ( + fun ({ name = name; shortdesc = shortdesc; + style = (ret, args, optargs) })...

> Is this just trying if the guestfs can be linked with? Yes. In OCaml bindings, there is the corresponding test( https://github.com/libguestfs/libguestfs/blob/master/ocaml/t/guestfs_010_load.ml). I just mimicked it. If it is not required, I will remove it. divided the generated files and handmade files in rust/src/ directory. I'll send this fixed patch to this mailing list. I'm not

On Mon, Jul 08, 2019 at 10:04:57AM +0100, Richard W.M. Jones wrote: >On Mon, Jul 08, 2019 at 10:49:55AM +0200, Martin Kletzander wrote: >> On Mon, Jul 08, 2019 at 10:10:10AM +0200, Pino Toscano wrote: >> >On Saturday, 6 July 2019 13:03:24 CEST Martin Kletzander wrote: >> >>Just one thing, the Cargo.toml includes a version under which the crate would be >>

...(e.g. CString, *const c_char) + * RawSOptArgs: Each field has raw pointers or integer values + * + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs + * + * Note: direct translation from SOptArgs to RawSOptArgs will cause a memory + * management problem. Using into_raw/from_raw, this problem can be avoided, + * but it is complex to handle freeing memories manually in Rust because of + * panic/?/etc. + *) + (* generate structs for optional arguments *) + List.iter ( + fun ({ name = name; shortdesc = shortdesc; + style = (ret, args, optargs) })...

...(e.g. CString, *const c_char) + * RawSOptArgs: Each field has raw pointers or integer values + * + * SOptArgs ---try_into()---> CExprSOptArgs ---to_raw()---> RawSOptArgs + * + * Note: direct translation from SOptArgs to RawSOptArgs will cause a memory + * management problem. Using into_raw/from_raw, this problem can be avoided, + * but it is complex to handle freeing memories manually in Rust because of + * panic/?/etc. + *) + (* generate structs for optional arguments *) + List.iter ( + fun ({ name = name; shortdesc = shortdesc; + style = (ret, args, optargs) })...

Hi Hiroyuki, sorry for the late reply. Most of the work is definitely nice! There are few notes below, although they are not big issues. I will check this patch once more on monday, especially the rust parts. Otherwise, I'd say that we are close to merging this :) On Tuesday, 23 July 2019 10:37:17 CEST Hiroyuki Katsura wrote: > From: Hiroyuki_Katsura

I fixed the patch I submitted before based on comments, and there are some commits which are merged or divided. So, I will re-send all the patches. Regards, Hiroyuki Katsura

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- Makefile.am | 4 ++++ configure.ac | 3 +++ generator/Makefile.am | 3 +++ generator/bindtests.ml | 3 +++ generator/bindtests.mli | 1 + generator/main.ml | 5 +++++ generator/rust.ml | 34 ++++++++++++++++++++++++++++++++++ generator/rust.mli | 19 +++++++++++++++++++