Skip to content

Commit 33c6546

Browse files
committed
rust: helpers: Clarify comment on size_t = uintptr_t guard
Also fix the guard to not fail spriously on ARM. We just need the types to be ABI-compatible; we don't need C to be willing to implicitly convert between them. Signed-off-by: Geoffrey Thomas <[email protected]>
1 parent fef0214 commit 33c6546

File tree

1 file changed

+21
-5
lines changed

1 file changed

+21
-5
lines changed

rust/helpers.c

+21-5
Original file line numberDiff line numberDiff line change
@@ -87,8 +87,24 @@ int rust_helper_cond_resched(void)
8787
}
8888
EXPORT_SYMBOL_GPL(rust_helper_cond_resched);
8989

90-
#if !defined(CONFIG_ARM)
91-
// See https://github.com/rust-lang/rust-bindgen/issues/1671
92-
static_assert(__builtin_types_compatible_p(size_t, uintptr_t),
93-
"size_t must match uintptr_t, what architecture is this??");
94-
#endif
90+
/* We use bindgen's --size_t-is-usize option to bind the C size_t type
91+
* as the Rust usize type, so we can use it in contexts where Rust
92+
* expects a usize like slice (array) indices. usize is defined to be
93+
* the same as C's uintptr_t type (can hold any pointer) but not
94+
* necessarily the same as size_t (can hold the size of any single
95+
* object). Most modern platforms use the same concrete integer type for
96+
* both of them, but in case we find ourselves on a platform where
97+
* that's not true, fail early instead of risking ABI or
98+
* integer-overflow issues.
99+
*
100+
* If your platform fails this assertion, it means that you are in
101+
* danger of integer-overflow bugs (even if you attempt to remove
102+
* --size_t-is-usize). It may be easiest to change the kernel ABI on
103+
* your platform such that size_t matches uintptr_t (i.e., to increase
104+
* size_t, because uintptr_t has to be at least as big as size_t).
105+
*/
106+
static_assert(
107+
sizeof(size_t) == sizeof(uintptr_t) &&
108+
__alignof__(size_t) == __alignof__(uintptr_t),
109+
"Rust code expects C size_t to match Rust usize"
110+
);

0 commit comments

Comments
 (0)