Repository navigation
Alignment at const time? #370
Description
I have the following function:
fn aligned_to(bytes: &[u8], align: usize) -> bool {
(bytes as *const _ as *const () as usize) % align == 0
}I'd like to make it a const fn, but if I just do that without changing the implementation, the compiler complains:
error: pointers cannot be cast to integers during const eval
--> src/lib.rs:1636:5
|
1636 | (bytes as *const _ as *const () as usize) % align == 0
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: at compile-time, pointers do not have an integer value
= note: avoiding this restriction via `transmute`, `union`, or raw pointers leads to compile-time undefined behavior
This thread implies that there's no way to get this to work today (even by using unstable features). Is there intended to be a concept of alignment and const time? Will code like this ever be possible to write? This is relevant to zerocopy since I'd like to be able to do reference casts at const time where the target type has an alignment requirement greater than 1.
Activity
RalfJung commentedon Oct 19, 2022
The best we could have is some kind of intrinsic
guaranteed_aligned_tothat can tell if the pointer is definitely sufficiently aligned, but might returnfalsewhen the answer is impossible to give at const time. (This is similar toguaranteed_eq.)Lokathor commentedon Oct 20, 2022
This is needed to be able to safely re-interpret slice references and single references at compile time. I don't know what the answer is, but this is a huge deal for ergonomics if it can happen.
RalfJung commentedon Oct 20, 2022
Also see rust-lang/rust#102795
Note that even the thing that can happen will be much more limited than the runtime version. For example, when allocating a slice of
u8, then no part of it will be 2-aligned. That is fundamental during const-eval and will never change. We simply cannot know if at runtime, the slice will be at an odd or even address, so any element on it might have an odd address and thus fail to be aligned.