Skip to content
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

bindgen fails to correctly convert the ~0ul constant on i368 architecture #2965

Open
Jakuje opened this issue Oct 29, 2024 · 2 comments
Open

Comments

@Jakuje
Copy link

Jakuje commented Oct 29, 2024

We have header files with the following definition, which should use the largest unsigned long value:

#define CK_UNAVAILABLE_INFORMATION ~0UL

These are different on 32b and 64b architectures (not our choice of types)

When bindgen processes this inptut, it generates the following line of rust code:

pub const CK_UNAVAILABLE_INFORMATION: CK_ULONG = 18446744073709551615;

which is obviously wrong as the rust compiler will very soon figure out:

 --> src/conformance/../pkcs11/bindings.rs:7:50
  |
7 | pub const CK_UNAVAILABLE_INFORMATION: CK_ULONG = 18446744073709551615;
  |                                                  ^^^^^^^^^^^^^^^^^^^^
  |
  = note: the literal `18446744073709551615` does not fit into the type `u32` whose range is `0..=4294967295`
  = note: `#[deny(overflowing_literals)]` on by default

This happens both with 0.69 and 0.70 versions.

Jakuje added a commit to Jakuje/kryoptic that referenced this issue Oct 29, 2024
This is a workaround for a bindgen, not setting the correct value
for unsigned long constants:

rust-lang/rust-bindgen#2965

Remove when the above issue is fixed.

Signed-off-by: Jakub Jelen <[email protected]>
simo5 pushed a commit to latchset/kryoptic that referenced this issue Oct 29, 2024
This is a workaround for a bindgen, not setting the correct value
for unsigned long constants:

rust-lang/rust-bindgen#2965

Remove when the above issue is fixed.

Signed-off-by: Jakub Jelen <[email protected]>
@pvdrz
Copy link
Contributor

pvdrz commented Oct 30, 2024

any luck when using the --clang-macro-fallback option?

@Jakuje
Copy link
Author

Jakuje commented Oct 30, 2024

Interesting. When using CLI of the bindgen 0.70.1, it looks like I am getting different results than what we get from the crate invocation during build process. This looks ok regardless the use of --clang-macro-fallback:

<mock-chroot> sh-5.2# cat input.h 
#define CK_UNAVAILABLE_INFORMATION ~0UL

<mock-chroot> sh-5.2# bindgen input.h -o bindings.rs
Failed to run rustfmt: Internal rustfmt error (non-fatal, continuing)
<mock-chroot> sh-5.2# cat bindings.rs && echo
/* automatically generated by rust-bindgen 0.70.1 */

pub const CK_UNAVAILABLE_INFORMATION : i32 = - 1 ;

So it sounds like this is not caused by the bindgen defaults, but by one of our callbacks, which looks like coming into the way:

https://github.com/latchset/kryoptic/blob/9e11dca89e8df270420e5c42aa51e1528c6799b3/build.rs#L23-L27

When I try to change this callback to the internal ULong, I am getting again the wrong value:

7 | pub const CK_UNAVAILABLE_INFORMATION: ::std::os::raw::c_ulong = 18446744073709551615;

So I assume this is not an issue of the default bindgen behavior, but the callbacks.

Adding just the following (hopefully correctly):

     bindgen::Builder::default()
+        .clang_macro_fallback()

does not make a difference in the output.

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

2 participants