Map size_t to usize by default and check compatibility (fixes #1901, #1903) #2062
Conversation
…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.
|
Note that this is a breaking change and needs to be released in a semver-incompatible version (so like 0.59). It's backwards-compatible with existing users passing Tests pass locally (except for #2061). Is there a way to do a test that asserts that bindgen fails? The following header is expected to fail unless you pass |
|
This a great PR, seems like a way better fix than the old one, which leads to a lot of nonportable pregenerated headers :( |
|
☔ The latest upstream changes (presumably be6d07a) made this pull request unmergeable. Please resolve the merge conflicts. |
|
This seems ok if tests pass, sorry for missing it. I can try to rebase and merge if you don't have the cycles to do it. |
|
I took the liberty of rebasing this PR and opening #2278. The tests are passing so it should be ready for review I think |
Bindgen now supports mapping size_t to usize by default and doing a build time check to ensure they are the same size. See rust-lang/rust-bindgen#2062.
Bindgen now supports mapping size_t to usize by default and doing a build time check to ensure they are the same size. See rust-lang/rust-bindgen#2062.
This addresses the underlying issue identified in #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 #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.