On 6/25/24 23:47, Manos Pitsidianakis wrote:
On Mon, 24 Jun 2024 20:14, Paolo Bonzini <pbonz...@redhat.com> wrote:
Yes, I agree. However, considering we haven't even checked the situation
with what language features are required by any idiomatic bindings vs the
1.63 version that we need to support for Debian, I think it's a bit
premature to make it mandatory.


FWIW, I just ran

`cargo msrv -- cargo check --target x86_64-unknown-linux-gnu`

And the result was `The MSRV is: 1.77.2`

and the most important issue was that the mem::offset_of! macro was unstable till then.

I looked for a way to avoid it and the most promising is https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=10a22a9b8393abd7b541d8fc844bc0df

Basically, you replace

    pub struct Foo {
        foo: i32,
        bar: i32
    }

with

    with_offsets! {
        #[repr(C)]  // mandatory
        pub struct Foo {
            foo: i32,
            bar: i32,
        }
    }

The macro walks the struct twice, once to actually declare it and once to determine the offsets using mem::size_of and mem::align_of. The result is something like

        #[repr(C)]  // mandatory
        pub struct Foo {
            foo: i32,
            bar: i32,
        }

        pub struct FooOffsets {
            foo: usize,
            bar: usize,
        }

        impl Foo {
            pub const offset_to: FooOffsets = FooOffsets {
                foo: 0,
                bar: 4,
            }
        }

(where 0 and 4 are actually the aforementioned computation based on size_of and align_of).

There are some limitations but the trick is really well done; the need for #[repr(C)] is not a problem for us (C<->Rust interoperability needs it anyway), and the implementation is fully "const". And though it only works for structs that use "with_offsets!", and with just one level of fields, the implementation of offset_of is trivial:

    macro_rules! offset_of {
        ($Container:ty, $field:ident) => {
            <$Container>::offset_to.$field
        };
    }

Anyhow, this should _not_ be in the first version that is committed---which, as you remarked in the v2, should focus on working build system integration. As long as we know it is doable, it can be left for later.

Paolo


Reply via email to