search for: bindgen

Dear Richard, > We have tended to avoid this in other languages because the results > can be very poor quality (eg. swig bindings are usually terrible). > However if the resulting code from bindgen is high quality and > accurately covers all the features that libguestfs bindings need then > we can consider it. Thank you for your reply. Actually, I have not used bindgen and I cannot guarantee the quality. However, in this bindings, generated structs are accessed not from bindings user b...

...wrapper to 'understand' the struct passed from C API, it is required to incorporate the definition of the struct in C into Rust code. I have two approaches. 1. Create raw struct(#[repr(C)]), which has the equivalent memory mapping to C struct and access through this struct in Rust 2. Use bindgen to create ffi struct from guestfs.h Each of them has advantages and disadvantages. # 1st approach This is highly dependent on the implementation of API because it is subject to the memory mapping of API struct. When the way struct is structured changes in API, you have to modify Rust bindings. In...

...ent memory mapping > to C struct and access through this struct in Rust ... this is what I did in nbdkit (although it is not generated, but written by hand in this case): https://github.com/libguestfs/nbdkit/blob/a5d94ab65110136680598677610868196ed71145/plugins/rust/src/lib.rs#L38 > 2. Use bindgen to create ffi struct from guestfs.h We have tended to avoid this in other languages because the results can be very poor quality (eg. swig bindings are usually terrible). However if the resulting code from bindgen is high quality and accurately covers all the features that libguestfs bindings need...

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here since that would break the C API. Can I ask, would it make sense for us to hard code in R_LEGACY_RCOMPLEX so that Rust can just i...

...ust can handle anonymous nested structures, or > what is the right mapping of the involved C types to Rust It's worth mentioning that Rust's RFC 2102 [1] defines unnamed structs and unions for the purpose of C interoperability, but it's not yet implemented. Would it help Rust's bindgen (and, potentially, other C declaration parsers) if R could optionally give a name to the anonymous union member, like it's done in Windows API [2]? -- Best regards, Ivan [1] https://github.com/rust-lang/rust/issues/49804 [2] https://devblogs.microsoft.com/oldnewthing/20170907-00/?p=96956

...u can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are right that this error is confused by bindgen's inability to handle anonymous types, but even without that it would be a breaking change in Rust because code that accesses r or c must now access the struct variant of the union and then access the struct field. Also, this code has to now be in an unsafe block because of the potential to rea...

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition for > Rcomplex. Then, our downstream code that uses that bindgen-generated > code caused rustc compiler errors such as: > |error[E0560]: union `libR_sys::Rcomplex` has no field n...

...t much of > a C person, so I didn't realise this change would be invisible to C > users. I suppose R's stability contract only applies to C, and > therefore changes that break other languages such as Rust are out of > scope. You are right that this error is confused by > bindgen's?inability to handle anonymous types, but even without that > it would be a breaking change in Rust because code that accesses r or > c must now access the struct variant of the union and then access the > struct field. Which I believe can be rephrased as that it also matters how R...

On 4/3/23 14:07, Michael Milton wrote: > Hi all, > > There seems to have been a breaking change in the R trunk caused by a fix > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that > relates to the layout of the Rcomplex typedef. Previously it was a struct, > but now it's a union by default >

This used to be a single patch, but I split it into two with the addition of struct Scatterlist. Again a bit new with Rust submissions. I was told by Gary Guo to rebase on top of rust-next, but it seems *very* behind? The first patch does not build on its own due to a dead_code warning. It is hard to not have dead code when one is adding infrastructure to be used by others at a later