-
Notifications
You must be signed in to change notification settings - Fork 700
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
size_t vs usize #1671
Comments
Hi! If you have any questions regarding this issue, feel free to make a comment here, or ask it in the If you intend to work on this issue, then add |
You're technically correct, I think (which is the best kind of correct ;)). In practice, in all platforms that I know of But we should probably avoid doing this transformation, should be straight-forward. |
Hi I'd like to work on this. Should the |
Hey @cmcavity! Thanks for your interest in working on this issue. It's now assigned to you! |
Fixed by the above PR. |
For posterity, a flag was added to revert to previous behavior: --size_t-is-usize |
Hi folks, I have a scenario where bindgen has generated a Here @emilio suggested I should try It's not clear to me if this is the same issue, as here you are talking about The issue starts with version 0.53 of bindgen. Can anyone shed some light? |
Bindgen by default will peek the right size depending on the target architecture. So if you run bindgen with a 64-bit target it'll use u64, with a 32-bit target it'll use u32. If you enable |
Ah, I see. I wonder why (Sorry for all the questions) |
Is bindgen able to assert that I was thinking of writing something to test this, but it seems like bindgen probably has enough access to the C compiler to make that check doable? |
Add an assertion that doing so is safe. See rust-lang/rust-bindgen#1671 Can't use static_assert from <linux/build_bug.h> because that's 5.1+-only, but the underlying _Static_assert compiler builtin is available widely. See torvalds/linux@6bab69c
Add an assertion that doing so is safe. See rust-lang/rust-bindgen#1671 Can't use static_assert from <linux/build_bug.h> because that's 5.1+-only, but the underlying _Static_assert compiler builtin is available widely. See torvalds/linux@6bab69c
Add an assertion that doing so is safe. See rust-lang/rust-bindgen#1671 Can't use static_assert from <linux/build_bug.h> because that's 5.1+-only, but the underlying _Static_assert compiler builtin is available widely. See torvalds/linux@6bab69c
@geofft potentially, but other than asserting and aborting if we detect it's not safe we couldn't do much else. We have |
Yeah, asserting and aborting is the behavior I want - the platforms where this is not true are niche and I'd have to change many other parts of my bindings to safely handle them, I think. This might be asking too much, but, one approach might be to revert the default back to treating |
fwiw, i agree with @geofft that bindgen's defaults for size_t_is_usize should be |
I've opened #1901 to encourage bindgen to change the default back to |
The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Signed-off-by: Sven Van Asbroeck <[email protected]>
The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Signed-off-by: Sven Van Asbroeck <[email protected]>
The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]>
On 32-bit arm, `size_t` and 'uintptr_t` are incompatible, which will trigger the static assertion. The bug which this guard protects against (rust-lang/rust-bindgen#1671) was fixed upstream as of rust-bindgen v0.53: rust-lang/rust-bindgen#1688 d650823839f7 ("Remove size_t to usize conversion") The current recommended rust-bindgen version for building the Linux kernel is v0.56, so the guard can be safely dropped. Out of an abundance of caution, remove the guard only if building for 32-bit arm. Signed-off-by: Sven Van Asbroeck <[email protected]> [normalized title] Signed-off-by: Miguel Ojeda <[email protected]>
…ng#1901, rust-lang#1903) This addresses the underlying issue identified in rust-lang#1671, that size_t (integer that can hold any object size) isn't guaranteed to match usize, which is defined more like uintptr_t (integer that can hold any pointer). However, on almost all platforms, this is true, and in fact Rust already uses usize extensively in contexts where size_t would be more appropriate, such as slice indexing. So, it's better for ergonomics when interfacing with C code to map the C size_t type to usize. (See also discussion in rust-lang/rust#65473 about how usize really should be defined as size_t, not uintptr_t.) The previous fix for rust-lang#1671 removed the special case for size_t and defaulted to binding it as a normal typedef. This change effectively reverts that and goes back to mapping size_t to usize (and ssize_t to isize), but also ensures that if size_t is emitted, the typedef'd type of size_t in fact is compatible with usize (defined by checking that the size and alignment match the target pointer width). For (hypothetical) platforms where this is not true, or for compatibility with the default behavior of bindgen between 0.53 and this commit, onwards, you can disable this mapping with --no-size_t-is-usize.
…ng#1901, rust-lang#1903) This addresses the underlying issue identified in rust-lang#1671, that size_t (integer that can hold any object size) isn't guaranteed to match usize, which is defined more like uintptr_t (integer that can hold any pointer). However, on almost all platforms, this is true, and in fact Rust already uses usize extensively in contexts where size_t would be more appropriate, such as slice indexing. So, it's better for ergonomics when interfacing with C code to map the C size_t type to usize. (See also discussion in rust-lang/rust#65473 about how usize really should be defined as size_t, not uintptr_t.) The previous fix for rust-lang#1671 removed the special case for size_t and defaulted to binding it as a normal typedef. This change effectively reverts that and goes back to mapping size_t to usize (and ssize_t to isize), but also ensures that if size_t is emitted, the typedef'd type of size_t in fact is compatible with usize (defined by checking that the size and alignment match the target pointer width). For (hypothetical) platforms where this is not true, or for compatibility with the default behavior of bindgen between 0.53 and this commit, onwards, you can disable this mapping with --no-size_t-is-usize.
…ng#1901, rust-lang#1903) This addresses the underlying issue identified in rust-lang#1671, that size_t (integer that can hold any object size) isn't guaranteed to match usize, which is defined more like uintptr_t (integer that can hold any pointer). However, on almost all platforms, this is true, and in fact Rust already uses usize extensively in contexts where size_t would be more appropriate, such as slice indexing. So, it's better for ergonomics when interfacing with C code to map the C size_t type to usize. (See also discussion in rust-lang/rust#65473 about how usize really should be defined as size_t, not uintptr_t.) The previous fix for rust-lang#1671 removed the special case for size_t and defaulted to binding it as a normal typedef. This change effectively reverts that and goes back to mapping size_t to usize (and ssize_t to isize), but also ensures that if size_t is emitted, the typedef'd type of size_t in fact is compatible with usize (defined by checking that the size and alignment match the target pointer width). For (hypothetical) platforms where this is not true, or for compatibility with the default behavior of bindgen between 0.53 and this commit, onwards, you can disable this mapping with --no-size_t-is-usize.
…ng#1901, rust-lang#1903) This addresses the underlying issue identified in rust-lang#1671, that size_t (integer that can hold any object size) isn't guaranteed to match usize, which is defined more like uintptr_t (integer that can hold any pointer). However, on almost all platforms, this is true, and in fact Rust already uses usize extensively in contexts where size_t would be more appropriate, such as slice indexing. So, it's better for ergonomics when interfacing with C code to map the C size_t type to usize. (See also discussion in rust-lang/rust#65473 about how usize really should be defined as size_t, not uintptr_t.) The previous fix for rust-lang#1671 removed the special case for size_t and defaulted to binding it as a normal typedef. This change effectively reverts that and goes back to mapping size_t to usize (and ssize_t to isize), but also ensures that if size_t is emitted, the typedef'd type of size_t in fact is compatible with usize (defined by checking that the size and alignment match the target pointer width). For (hypothetical) platforms where this is not true, or for compatibility with the default behavior of bindgen between 0.53 and this commit, onwards, you can disable this mapping with --no-size_t-is-usize.
Add an assertion that doing so is safe. See rust-lang/rust-bindgen#1671 Can't use static_assert from <linux/build_bug.h> because that's 5.1+-only, but the underlying _Static_assert compiler builtin is available widely. See torvalds/linux@6bab69c
Input C/C++ Header
bindgen converts
size_t
to `usize. but I'm not sure that's correct. the unsafe guidelines(https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html) say that usize==uintptr_t. but the C standard doesn't define that uintptr_t==size_t therefore usize != size_t.Am I missing something?
The text was updated successfully, but these errors were encountered: