* Rust: Manual reimplementation of C unions and layout testing
@ 2025-10-21 21:02 Igor Korotin
2025-10-21 21:22 ` Matthew Maurer
0 siblings, 1 reply; 2+ messages in thread
From: Igor Korotin @ 2025-10-21 21:02 UTC (permalink / raw)
To: Danilo Krummrich, Miguel Ojeda, Daniel Almeida, Alice Ryhl,
Alex Gaynor, Benno Lossin, Björn Roy Baron, Boqun Feng,
Trevor Gross, Andreas Hindborg, rust-for-linux
Hello all,
As you might know, I'm working on the Rust side of the I2C subsystem,
and currently looking into representing `struct i2c_algorithm`.
In C, this struct contains two anonymous unions for callbacks.
bindgen generates rather awkward names for them, which makes the Rust
bindings less readable and less stable.
I'm considering declaring this structure manually in i2c.rs, effectively
copying the layout that bindgen would generate but renaming the union
fields for clarity. To avoid accidental ABI drift, I could add
compile-time assertions to ensure the Rust and C layouts remain compatible.
Would that be an acceptable approach?
Any thoughts or preferences on how such layout checks should be done
in-tree?
Best regards,
Igor Korotin
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Rust: Manual reimplementation of C unions and layout testing
2025-10-21 21:02 Rust: Manual reimplementation of C unions and layout testing Igor Korotin
@ 2025-10-21 21:22 ` Matthew Maurer
0 siblings, 0 replies; 2+ messages in thread
From: Matthew Maurer @ 2025-10-21 21:22 UTC (permalink / raw)
To: Igor Korotin
Cc: Danilo Krummrich, Miguel Ojeda, Daniel Almeida, Alice Ryhl,
Alex Gaynor, Benno Lossin, Björn Roy Baron, Boqun Feng,
Trevor Gross, Andreas Hindborg, rust-for-linux
On Tue, Oct 21, 2025 at 2:04 PM Igor Korotin
<igor.korotin.linux@gmail.com> wrote:
>
> Hello all,
>
> As you might know, I'm working on the Rust side of the I2C subsystem,
> and currently looking into representing `struct i2c_algorithm`.
>
> In C, this struct contains two anonymous unions for callbacks.
In the specific case of `struct i2c_algorithm`, all the unions are
solely for the sake of supporting both a deprecated name and a new
name, e.g.`master_xfer` (deprecated) vs `xfer` (current). Since the
Rust bindings should never need to reference the deprecated name, you
could consider proposing an `#ifdef __BINDGEN__` which removes the
`union` and *only* includes the new name.
> bindgen generates rather awkward names for them, which makes the Rust
> bindings less readable and less stable.
You should only need to reference the bindings name in exactly one
location, when translating from your Rust representation to the
bindings C representation or vice versa. You could also apply a
wrapper struct and create accessors if you really don't want to be
proxying between two types.
>
> I'm considering declaring this structure manually in i2c.rs, effectively
> copying the layout that bindgen would generate but renaming the union
> fields for clarity. To avoid accidental ABI drift, I could add
> compile-time assertions to ensure the Rust and C layouts remain compatible.
The problem is that those compile-time assertions will require to to
reference the bindgen struct, or invoke some kind of C parser on the
header or debug information, which is much more complex than just
referencing the field.
>
> Would that be an acceptable approach?
> Any thoughts or preferences on how such layout checks should be done
> in-tree?
tl;dr: Such layout checks should be done by bindgen, and I don't think
that unions where you only ever need to reference one arm ought to be
considered complex enough that we try to implement custom layout
checks.
>
> Best regards,
> Igor Korotin
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-10-21 21:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-21 21:02 Rust: Manual reimplementation of C unions and layout testing Igor Korotin
2025-10-21 21:22 ` Matthew Maurer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).