| 1 | |
| 2 |
|
| 3 | #include <linux/build_bug.h>
|
| 4 |
|
| 5 | |
| 6 | * `bindgen` binds the C `size_t` type as the Rust `usize` type, so we can
|
| 7 | * use it in contexts where Rust expects a `usize` like slice (array) indices.
|
| 8 | * `usize` is defined to be the same as C's `uintptr_t` type (can hold any
|
| 9 | * pointer) but not necessarily the same as `size_t` (can hold the size of any
|
| 10 | * single object). Most modern platforms use the same concrete integer type for
|
| 11 | * both of them, but in case we find ourselves on a platform where
|
| 12 | * that's not true, fail early instead of risking ABI or
|
| 13 | * integer-overflow issues.
|
| 14 | *
|
| 15 | * If your platform fails this assertion, it means that you are in
|
| 16 | * danger of integer-overflow bugs (even if you attempt to add
|
| 17 | * `--no-size_t-is-usize`). It may be easiest to change the kernel ABI on
|
| 18 | * your platform such that `size_t` matches `uintptr_t` (i.e., to increase
|
| 19 | * `size_t`, because `uintptr_t` has to be at least as big as `size_t`).
|
| 20 |
|
| 21 | static_assert(
|
| 22 | sizeof(size_t) == sizeof(uintptr_t) &&
|
| 23 | __alignof__(size_t) == __alignof__(uintptr_t),
|
| 24 | "Rust code expects C `size_t` to match Rust `usize`"
|
| 25 | );
|