Bindgen converts `char` to `c_schar` instead of `c_char`

[crumblingstatue]

Input C/C++ Header

struct foo {
	char member;
};

Bindgen Invokation

bindgen foo.h

Actual Results

/* automatically generated by rust-bindgen */

#[repr(C)]
#[derive(Debug, Copy)]
pub struct foo {
    pub member: ::std::os::raw::c_schar,
}
#[test]
fn bindgen_test_layout_foo() {
    assert_eq!(::std::mem::size_of::<foo>() , 1usize , concat ! (
               "Size of: " , stringify ! ( foo ) ));
    assert_eq! (::std::mem::align_of::<foo>() , 1usize , concat ! (
                "Alignment of " , stringify ! ( foo ) ));
    assert_eq! (unsafe {
                & ( * ( 0 as * const foo ) ) . member as * const _ as usize }
                , 0usize , concat ! (
                "Alignment of field: " , stringify ! ( foo ) , "::" ,
                stringify ! ( member ) ));
}
impl Clone for foo {
    fn clone(&self) -> Self { *self }
}

Expected Results

The field should be c_char, not c_schar. char is not defined as always signed in the C standard. It can be unsigned.

[crumblingstatue]

From a short investigation, it seems that bindgen only knows about char, which maps to c_schar, and unsigned char, which maps to c_uchar. But there are 3 types.

| C             | Rust    |
+---------------+---------+
| char          | c_char  |
| signed char   | c_schar |
| unsigned char | c_uchar |

[emilio]

The field should be c_char, not c_schar. char is not defined as always signed in the C standard. It can be unsigned.

Right, but LLVM takes care of figuring out signedness for us. See #559.

[crumblingstatue]

Right, but LLVM takes care of figuring out signedness for us. See #559.

Maybe so when bindgen is used as part of the build process for the target platform, but this doesn't work when generating one set of bindings that's meant to be used on all platforms, using the command line application.

Or is this mode of operation now unsupported?

1. Generating a different binding for every target platform would be tedious and repetitive, but this is the more viable option for me, because:

2. Using bindgen as part of the build process has several problems:

   • It requires that everyone who wants to build my crate has Clang.
   • It results in an enormous blowup in compile times for my crate, because bindgen has to be compiled.
   • The bindgen output by itself is unusable because of several issues, most notably Option for only generating bindings for filenames matching a pattern #303. I have to edit the generated bindings for it to be usable. This would mean I would have to write software to manipulate the bindgen output instead of doing the editing manually.

[emilio]

Or is this mode of operation now unsupported?

I guess that has only ever worked because of the platforms people generate bindings in happen to have signed chars.

I guess this would need a bit of a hack to work, but I believe it can be done.

In particular, we could try to check the type spelling to see if it doesn't contain neither signed or unsigned, and use that... Assuming the spelling clang gives us is the proper one.

[dimbleby]

I guess that has only ever worked because of the platforms people generate bindings in happen to have signed chars.

The reason this "ever worked" is that it had only been broken for three weeks when reported (4f1e3da).

I'm completely in agreement with what @crumblingstatue says about wanting to generate bindings offline. So "me too" on this one.

[emilio]

The reason this "ever worked" is that it had only been broken for three weeks when reported (4f1e3da).

The point is that before that change, we used char when libclang reported a signed char.

[dimbleby]

Yes, I understand. But I guess that it's much more common for C APIs to use char than it is explicitly to use signed char - at any rate, that's true in the case of the API that I care about.

So I expect we've switched from "uncommon case is broken" to "common case is broken".

[dimbleby]

It looks easy enough to 90% fix this, by which I mean convert types correctly from C to Rust. But there are still some places where bindgen asks whether a type is signed, and it's obviously impossible to give a universal definitive answer for char.

Let me put together a pull request...

[fitzgen]

@emilio @dimbleby @crumblingstatue Can this issue be closed now?