0.15 - The API hash is different between 64-bit and 32-bit builds

[enbyted]

The generated API hash seems to depend on pointer width somehow.
When building for i686-pc-windows-msvc and x86_64-pc-windows-msvc the generated API version hash is different even though the rust source and generated c# (apart form the hash) remains the same.

I believe this is a bug - ABI mismatch on this level will be detected by the operating system - you cannot load a 32-bit library into 64-bit process and vice versa. If otherwise bindings stay the same then hashes should be the same.

In particular, this requires me to modify the generated c# bindings in order to support AnyCPU builds. For that I have to choose at runtime (depending on what architecture I'm running on) which DLL to load and thus I have to adjust the bindings to support 2 different hashes.

[ralfbiedert]

Would you have a minimal example where this happens? I'd suspect this is caused by an usize or so in a function signature, but it would be good to verify.

[enbyted]

I'll try to make something.
I don't think I have any usize in my types, but I do take in some types by reference, which could be causing this as well. In c# they require you to pass a raw pointer, which 1) may be the culprit and 2) is a little awkward (could they use a ref argument instead?).

[ralfbiedert]

In c# they require you to pass a raw pointer, which 1) may be the culprit and 2) is a little awkward (could they use a ref argument instead?).

Many types should translate to ref already, but some don't have a good or simple C# mapping like string refs so they become IntPtr. Feel free to add an example what goes wrong.

[enbyted]

A bit unexpected but here is the minimal repro:

use interoptopus::{
    ffi_function, function,
    inventory::{Inventory, InventoryBuilder},
    pattern::api_guard::ApiHash,
};

#[ffi_function]
fn my_fn() {}

#[test]
fn it_works() {
    let version = ApiHash::from(&InventoryBuilder::new().register(function!(my_fn)).build());

    // x86_64-unknown-linux-musl
    // aarch64-apple-darwin
    #[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))]
    assert_eq!(version.hash, 17011914719601635527);
    // i686-unknown-linux-musl
    #[cfg(target_arch = "x86")]
    assert_eq!(version.hash, 4479287528157645169);
}

Build with:
cargo test --target x86_64-unknown-linux-musl
and
cargo test --target i686-unknown-linux-musl

And it will pass in both cases thanks to the cfg, but obviously that is unexpected.

[enbyted]

I had a look into what might be causing this and it turns out to be reliance on #[derive(Hash)] for enums with default representation. The following demonstrates this:

#[test]
fn it_works() {
    use std::hash::{DefaultHasher, Hash, Hasher};

    #[derive(Hash)]
    enum Test {
        A,
        B,
    }

    let mut hasher = DefaultHasher::new();
    Test::A.hash(&mut hasher);
    // i686-unknown-linux-musl
    #[cfg(target_arch = "x86")]
    assert_eq!(hasher.finish(), 14709398186846620400);
    // x86_64-unknown-linux-musl
    #[cfg(target_arch = "x86_64")]
    assert_eq!(hasher.finish(), 13646096770106105413);
}

Currently the derived Hash implementation uses core::intrinsics:: discriminant_value() for its implementation, but that hasn't always been the case and is not in any way guaranteed by rust. It seems to be treated like an usize, but again - this is not guaranteed.
A possible solution to this is to use #[repr(u32)] on all enums that are contained in Inventory - though I'm not 100% convinced that it is guaranteed to be stable with the derived Hash impl - seems to work right now at least.

Also, the usage of DefaultHasher is a little problematic as it has no guarantees on its implementation:

The internal algorithm is not specified, and so it and its hashes should not be relied upon over releases.

Thus, it is possible that the library will stop working just because it got built with a newer compiler, even though the ABI has stayed the same (as guaranteed by the usage of extern "C").

All in all, it seems to me that using the default Hash trait may not be the best option for this purpose.