Wrong offset of CxxString field when preceded by padding

[google]

Wrong offset of CxxString field when preceded by padding

[adetaylor]

Right, the problem here is that I (stupidly) hadn't realized field access was even possible via UniquePtr. Oops. I was expecting field access to opaque types solely to be possible only via accessor methods in C++ which I have yet to generate.

(The solution is probably for autocxx to generate a blank struct for things which are opaque, such that there are no fields to have the wrong offsets.)

[dtolnay]

The solution is probably for autocxx to generate a blank struct for things which are opaque, such that there are no fields to have the wrong offsets.

Public fields should be fine as long as there is a way to find out the presence of padding from bindgen. (I have never looked into what information bindgen has; you might already have considered this and it's not possible or would be too platform-specific.)

The Rust struct I would expect generated for that input would be something like:

#[repr(C)]
pub struct S {
    pub i: u32,
    _padding0: [u8; 4],
    pub s: ::cxx::CxxString,
    _actual_s: [u64; 3],
}

Notice not all fields are pub which makes the struct not constructible from Rust with an S { ... } struct literal expression, but that is fine because it shouldn't be constructible by value in Rust anyway.

This way we're still able to take references to s for passing to C++ or calling e.g. the Debug impl of CxxString.

[dtolnay]

Oh here is a way that would only use information that the current implementation is already using:

#[repr(C)]
pub struct S {
    pub i: u32,
    _align_s: [[u64; 3]; 0],  // [T; 0] where T is the type of _actual_s determined through bindgen
    pub s: ::cxx::CxxString,
    _actual_s: [u64; 3],
}

[adetaylor]

as long as there is a way to find out the presence of padding from bindgen. (I have never looked into what information bindgen has; you might already have considered this and it's not possible or would be too platform-specific.)

Unfortunately, there be doom here.

The relevant limitation on bindgen is lack of support for template specialization. It seems from my explorations that any real STL type except std::unique_ptr involves partial template specialization and therefore the layout cannot be accurately calculated by bindgen. In fact, in autocxx, we replace std::string with a nonsense fictional type as it simply failed to deal with the real std::string at all. (I can't remember the exact symptoms, but they seemed definitively doomed, and expected).

This leads to an interesting and worrying question though.

In cxx, we have:

• Opaque
• Trivial - no non-trivial move constructor, no destructor

For the purposes of field access, we need something slightly different:

• "Plain old data" - bindgen can calculate field offsets correctly
• Not POD - bindgen can't due to std::string or other type that might involve template specialization.

These things have been 100% correlated so far, but they're not the same and I'll need to be aware of this. #17 is therefore possibly just wrong.