-
Notifications
You must be signed in to change notification settings - Fork 743
Bindgen generates inconsistent enum representations on Windows and Unix #1244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Huh, interesting, which target are you passing to bindgen when cross-compiling? Afaict we just use the type that clang gives us. |
@emilio I'm cross-compiling to the |
* Temporary hacks for rust-lang/rust-bindgen#1244 * Implement WindowHandle trait * Add rudimentary EGL support (see renderdoc/issues#853) * Fix compilation bugs with Windows and winapi * Modernize triangle example * Change replay wrapper filenames to snake case
Sorry I couldn't look at this during the week. clang is returning us the signed integer type, instead of the unsigned one. I think this is not a bindgen (nor clang) bug, and it's a bogus assumption that the enum ends up unsigned. In particular, see https://godbolt.org/g/p6tBZP. MSVC is the only compiler that fails to compile that program, but passes if I replace I'm closing this because of the above, but please let me know if I got it wrong. Thanks a lot for the report! MSVC never stops to amuse me :) |
For reference, just in case the godbolt link expires or something, the program is: #include <type_traits>
extern "C" {
typedef enum {
eRENDERDOC_Overlay_All = ~0U,
} RENDERDOC_OverlayBits;
}
int main() {
static_assert(
std::is_same<std::underlying_type<RENDERDOC_OverlayBits>::type, unsigned>::value,
"Huh");
} |
It may be worth to point this up to upstream renderdoc, just in case it causes some weird behavior on windows. |
…ants This is a fix for: #29 The existing code assumed that the Wolfram LibraryLink constants would have the same size and signedness on all platforms. This assumption was not correct on Windows targeting MSVC, where constants that would be u32 on other platforms would be i32. See also: * rust-lang/rust-bindgen#1244 * rust-lang/rust-bindgen#1361
…ants (#41) This is a fix for: #29 The existing code assumed that the Wolfram LibraryLink constants would have the same size and signedness on all platforms. This assumption was not correct on Windows targeting MSVC, where constants that would be u32 on other platforms would be i32. See also: * rust-lang/rust-bindgen#1244 * rust-lang/rust-bindgen#1361
I am working on some Rust bindings for RenderDoc, and I am trying to replace my hand-rolled FFI code with bindgen. However, I am running into an issue with incorrect and inconsistent enum representations between Windows and Unix-likes, where on Windows, the resulting code doesn't even compile when integrated into my bindings.
The bug is caused due to a single line in the input code below, and appears to be tangentially related to #1185.
Input C/C++ Header
Bindgen Invocation
Actual Results
On Unix, bindgen correctly outputs:
When cross-compiling on Unix to Windows, bindgen incorrectly outputs:
Expected Results
The correct enum representation in this case should have been
uint32_t
on both platforms. I would like to see better support for~0U
/u32::MAX
on the bindgen side of things.The text was updated successfully, but these errors were encountered: