long double becomes u128

[aDotInTheVoid]

Input C/C++ Header

typedef long double foo

Bindgen Invocation

$ bindgen input.h 

Actual Results

/* automatically generated by rust-bindgen */

pub type a = u128;

Expected Results

I'm not entirely sure. Here are the idea's I can think of

• use f64, but that leeds to it's own set of issues (Incorrect size for long double when using old rust_target #1529).
• use the f128 crate but the layout of the f128 is different to the layout of a c long double
• add a c_longdouble type to std::os::raw. The problem is that on many machines (including mine) long double is a 16 byte float, which rust doesn't suport
• Through an error. This will avoid confusion, but also make also will mean losing suport for many .h files
• use u128. The problem here is were treating a float as an int, and that will mean all sorts of problems

[emilio]

I find all the first ones are strictly worse than the current behavior. With the current behavior at least you don't have ABI issues, and you can pass it by value transparently to C / C++.

Unfortunately erroring out is a no-go since it's used in a lot of standard headers to implement max_align_t.

[aDotInTheVoid]

Maybe the best option would be to still use u128, but then give a warning that passing u128 values to c funcs that take long double won't behave normally.

It might also make sense to provide a way of converting f64/f32/fsize to u128 and vice verse

[emilio]

Well, it will behave normally, right? As in, a long double value that you got from C should be fine to be passed to C again. It's only constructing rust values what's impossible / hard.

[parasyte]

rustc also emits warnings about this:

warning: `extern` block uses type `u128` which is not FFI-safe: 128-bit integers don't currently have a known stable ABI

You're right, it should behave correctly, at least where long double is 16-bytes, barring any strange alignment issues. But expecting Rust to treat these types as a black box is unrealistic. :) Constructing isn't the only problem, but also reading and writing the values from Rust.

[Lokathor]

I also hit this just now, using SDL2. Throwing an error is obviously bad and not acceptable.

Could we, for the time, emit some sort of dummy struct value with a meaningful name that's the correct size and alignment, and then has the bits as an inner field. This would at least make it very obvious that you should be treating it as a black box if you get it from C, though perhaps an expert could throw a lib at it or something if they really needed f128 support.

If a type is added to std::os::raw be sure to also add it to libc as well so that no_std can use it.

[emilio]

Could we, for the time, emit some sort of dummy struct value with a meaningful name that's the correct size and alignment, and then has the bits as an inner field. This would at least make it very obvious that you should be treating it as a black box if you get it from C, though perhaps an expert could throw a lib at it or something if they really needed f128 support.

Probably not, since in MSVC struct vs. POD type matters ABI-wise, and I think it'd break.

[Lokathor]

you'd want to use repr(transparent)

#[repr(transparent)]
pub struct IAmF128PleaseDontTouch {
  raw: u128
}

EDIT: well that gives the right size, but I do not know about the right alignment

[emilio]

Yeah, #[repr(transparent)] should be fine, though bindgen supports not generating repr(transparent). But as long as we fallback to the current behavior if there's no #[repr(transparent)] support it should be ok, yeah.

[smarnach]

In gcc and clang on x86_64, long double has an alignment of 16, whereas u128 has an alignment of 8. This means structs containing a long double usually end up with broken layouts. So far I haven't found a good work-around for this problem.

[elichai]

What about something like this:

#[repr(C, align(16))]
struct f128 {
    a: [u8; 16]
}