Skip to content

Fails to generate correct code when UINT64_C is used #3200

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

Open
Kriskras99 opened this issue Apr 28, 2025 · 5 comments
Open

Fails to generate correct code when UINT64_C is used #3200

Kriskras99 opened this issue Apr 28, 2025 · 5 comments

Comments

@Kriskras99
Copy link
Contributor

I understand that getting the correct integer type from #define is very difficult, however using UINT64_C should clarify to bindgen that it's a 64-bit integer. Currently the macro parser fails on UINT64_C and the Clang macro fallback is needed, but that still generates a 32-bit integer.

Header:

#include <stdint.h>
#define SOMETHING UINT64_C(1)

Without --clang-macro-fallback:

bindgen --allowlist-item SOMETHING header.h

Output:

/* automatically generated by rust-bindgen 0.71.1 */


With --clang-macro-fallback:

bindgen --clang-macro-fallback --allowlist-item SOMETHING header.h

Output:

/* automatically generated by rust-bindgen 0.71.1 */

pub const SOMETHING: u32 = 1;
@Kriskras99
Copy link
Contributor Author

If this is not possible to do, you can just close this issue. But it feels like something that bindgen could do.

@ojeda
Copy link
Contributor

ojeda commented Apr 29, 2025

Cc: @jbaublitz

@jbaublitz
Copy link
Contributor

Hi @Kriskras99, this has to do with the type of integers reported by Clang when evaluating macro bodies. It does not report a size so it ends up defaulting to a 32-bit width integer. Now theoretically we could make all of these integers 64-bit, but until Clang reports the correct size in this context, we can't really take a more fine-grained approach. We rely on Clang to report that information elsewhere in bindgen.

@Kriskras99
Copy link
Contributor Author

Thanks for the detailed explanation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants