Emilio Cobos Álvarez

Definitely not! I'll try to get to it and provide some feedback, but I don't close PRs unless they're superseded by other work, is definitely-unwanted functionality, or have gone completely...

That said, a high-level question from taking a look at Zig and so on: Is there anything cbindgen would be able to do that `@cImport`-ing a cbindgen-generated header wouldn't? Just...

Can you provide a concrete example? We have https://github.com/eqrion/cbindgen/blob/798cfab52bced65a749443faa16990ec3a8e0cfe/src/bindgen/config.rs#L935-L937

The layout of these is defined, btw, in https://github.com/rust-lang/unsafe-code-guidelines/blob/master/reference/src/layout/pointers.md

Yeah, I think that the history of the code went something like on the the first iteration, `derive_helper_methods`, generated both `IsFoo()` and `static Foo()` methods. Then the casts were added,...

Ah, this is because cbindgen calls cargo to generate crate graph metadata information, so in your case it creates a `Cargo.lock` file. Checking the file into the repository may work....

(To be clear, above I meant "checking `Cargo.lock` into the repository". I believe that would fix it.

> However, this is not necessarily correct. cbindgen needs to specify the type of the enum class using the same method that C does. Can you elaborate? C uses `int`...

Can you `printf("size: %zu\n", sizeof(Error));` on your target? Are you compiling with flags that shrink the enum or something? I've remember seeing such flags at some point

If `#[repr(C)]` in rust disagrees with `enum Foo` in some platforms, that seems like a `rustc` bug rather than a cbindgen bug, IMO.