i128 / u128 are not compatible with C's definition.

[emilio]

While fixing various bindgen bugs related to long double, int128, (rust-lang/rust-bindgen#1370, etc).

I realized that the following Rust program, in my x86_64 Linux machine:

#[repr(C)]
struct Foo {
    f: u128,
}

fn main() {
    println!("Align: {}", ::std::mem::align_of::<Foo>());
}

Prints 8.

While the following C program:

#include <stdio.h>

struct foo {
  unsigned __int128 t;
};

int main() {
  printf("Align: %ld\n", _Alignof(struct foo));
}

Prints 16 on the same system. This is pretty unexpected, and means that i128 / u128 are not really usable for FFI / alignment purposes.

[vext01]

I think the correct fix would be to add long_double type to libc with the correct alignment.

I guess that's probably not hard? I could have a go at that if it sounds like the right thing to do.

[nagisa]

This is a bug in llvm. There was an attempt to fix this in the past, but it got reverted because of reasons.

The sysV __int128 should be 16-byte aligned and rust follows that ABI.

[nagisa]

Rather, this is blocked on LLVM data-layouts getting fixed, because rustc expects them to be matched last time I checked.

[emilio]

Ugh, thanks @nagisa... I think this is also a problem for long double, reading that LLVM patch they'd align it to 64 bits. Sigh.

#include <stdio.h>

struct foo {
  long double bar;
};

int main() {
  printf("%ld\n", _Alignof(struct foo)); // 16
}

[strega-nil]

Copying from the last thread, since this thread seems to mostly be about long double.

In C and C++, on x86_64 Linux, alignof(__int128) is equal to 16. However, in Rust, align_of::() is equal to 8.

C++: https://gcc.godbolt.org/z/YAq1XC
Rust: https://gcc.godbolt.org/z/QvZeqK

This will cause subtle UB if you ever try to use i128s across FFI boundaries; for example:

C++: https://gcc.godbolt.org/z/PrtHlp
Rust: https://gcc.godbolt.org/z/_SdVqD

[gnzlbg]

The improper_ctypes warning diagnoses usage of these types in C FFI, so at least users are alerted that this does not work. Playground

[gnzlbg]

@Centril @eddyb this should be I-unsound.