Generated tests are not compatible across architectures

[kornelski]

Input C/C++ Header

struct Foo {
   int bar;
};

Bindgen Invocation

Run on x86_64-apple-darwin:

$ bindgen input.h

Test with: cargo test --target=i686-apple-darwin

Actual Results

fn bindgen_test_layout_Foo ( ) …

Expected Results

The tests are valid only on the architecture bindgen was run on. It would be great if bindgen was able to make tests portable, e.g.:

#[cfg(target_pointer_width = "64")]
fn bindgen_test_layout_Foo ( ) …

#[cfg(target_pointer_width = "32")]
fn bindgen_test_layout_Foo ( ) …

Currently this isn't easy to do even manually, because tests are interleaved with other code, so combining of 32- and 64-bit files requires advanced regex-fu.

[emilio]

It's pretty hard to do that, it not only depends on architecture but also on compiler flags and what not...

[emilio]

We support not generating tests of course, but that's not quite a solution...

[fitzgen]

Best thing to do is either generate bindings for the current target in build.rs or generate bindings for each target you plan to support and check them into your version control.

There is a lot more gotchas than just pointer width, and the biggest is #ifdefs that change definitions based on target arch or os etc.

[kornelski]

IIRC all of the platform-specific ifdefs that I had to deal with were only used to get reliable/cross-platform fixed-size types (in codebases that think depending on stdint.h is too radical).

For libraries with stable ABI I prefer to generate bindings once and clean them up by hand, because it also allows me to translate feature-specific ifdefs into Cargo features.

[kornelski]

I think the minimal fix here would be to add #[cfg(target_pointer_width = "…")] (or target_arch?) to the tests, so that at least they don't give false negatives on other architectures.

Sorting of output to put all tests at the end would be helpful, too.

[Dushistov]

@kornelski

For libraries with stable ABI I prefer to generate bindings once
I think the minimal fix here would be to add target_arch
to the tests

But what about generated bindings by itself?
For example for:

#include <stdint.h>

union Foo {
        void *p;
        uint32_t a;
};

bindgen generate different code for different platforms:

#[repr(C)]
#[derive(Copy, Clone)]
pub union Foo {
    pub p: *mut ::std::os::raw::c_void,
    pub a: u32,
    _bindgen_union_align: u32,
}

#[repr(C)]
#[derive(Copy, Clone)]
pub union Foo {
    pub p: *mut ::std::os::raw::c_void,
    pub a: u32,
    _bindgen_union_align: u64,
}

and failed tests indicates that something wrong, and you should generate bindings in target directory, if tests don't fail with different --target=, then you may assume that all good, while really all bad.

May be leave current behaviour as is, because of it prevents errors and bugs?

[kornelski]

In your example I actually don't know why bindgen does it this way, because ::std::mem::align_of::<::Foo>() is also correct without bindgen's extra field (4 on i686, 8 on x86_64).

I'm working under assumption that #[repr(C)] struct used with ::std::os::raw::c_* types (and raw pointers) is correct for C without bindgen's hacks if C doesn't use extra pragmas for packing structs, custom align or C++ features. Fortunately these assumptions happen to be true very often for small libraries with C ABI.

[emilio]

Yeah we could avoid generating the alignment for the union in some cases, I'm happy to accept patches for that as long as there are proper tests.