Tracking Issue for `const_align_offset`

[WaffleLapkin]

Feature gate: #![feature(const_align_offset)]

This is a tracking issue for <*const _>::align_offset and <*mut _>::align_offset functions marked as const fn

Public API

impl<T> *const T {
    pub const fn align_offset(self, align: usize) -> usize;
}

impl<T> *mut T {
    pub const fn align_offset(self, align: usize) -> usize;
}

impl <T> NonNull<T> {
    pub const fn align_offset(self, align: usize) -> usize;
}

Steps / History

• Implementation: Mark <*const _>::align_offset and <*mut _>::align_offset as const fn #90958
• NonNull methods stabilized, constness moved to this gate Stabilize non_null_convenience #124498
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Is it fine to always return usize::MAX at compile time? This allows to distinguish compiletime and runtime function execution, see Make slice->str conversion and related functions const #90607 (comment)

[RalfJung]

This allows to distinguish compiletime and runtime function execution, see #90607

I agree this is a problem, but sadly the link seems to just go to the PR (links to collapsed discussions don't seem to work) so I have no idea what this has to do with the UTF8 methods -- could someone explain the connection? Is it just because align_offset is indirectly being called there? Or can the UTF8 methods themselves be used to do a CTFE/runtime distinction?

[WaffleLapkin]

@RalfJung I've unresolved the discussion, now the link should be working (it's the first discussion in the PR).

TL;DR: originally in #90607 I've used const_eval_select in the methods that check utf8 validity to make them available in const fn. const_eval_select just replaced call to align_offset to usize::MAX there, this is valid per the documentation of align_offset - it can spuriously return usize::MAX. In the discussion, it was argued that the same reasoning can be applied to any correct use of align_offset.

[RalfJung]

any correct use of align_offset

Emphasis mine. :) Safe code can easily use align_offset incorrectly. So this is not something we can rely on for safety concerns.

[phip1611]

@WaffleLapkin Can you please explain why the const implementation always returns usize::MAX? Please look at the following example that does not work because of this limitation:

#![feature(const_align_offset)]
#![feature(const_mut_refs)]

#[repr(align(4096))]
struct PageAligned<T>(T);
static mut MEMORY: PageAligned<[u8; 1]> = PageAligned([0; 1]);

struct Foo;
impl Foo {
    const fn new(mem: &[u8]) -> Self {
        assert!(mem.as_ptr().align_offset(4096) == 0, "memory must be page aligned!");
        Self
    }
}
static FOO: Foo = unsafe {Foo::new(&mut MEMORY.0)};


fn main() {}

This currently prevents me from doing an alignment check inside the constructor. Is this intended? What is a possible solution?

[WaffleLapkin]

@phip1611 during CTFE (compile time function execution) memory is organized differently, than while runtime execution Specifically it doesn't really have addresses or alignment, so there is no way to implement align_offset in a sensible way. (PS I'm not an expert in CTFE, so correct me if I'm wrong)

Also, see the documentation:

If it is not possible to align the pointer, the implementation returns usize::MAX. It is permissible for the implementation to always return usize::MAX. Only your algorithm’s performance can depend on getting a usable offset here, not its correctness.

align_offset is expected to be used in cases where you can process adjacent elements of an array at the same time, if they are aligned, but you can also process them one-by-one otherwise. I don't think that your use case fits here.

Also note that this function is unlikely to be stabilized in it's current form as a const fn since it allows to distinguish runtime and compile time execution.

[phip1611]

Thanks for the quick reply @WaffleLapkin. What do you think about the use case shown in my example? Shouldn't this be possible in the future? Do you think it is worth it to open a dedicated ticket for this?

[WaffleLapkin]

@phip1611 I don't think this can be ever possible, addresses of static variables are not known at compile time and are even randomized at runtime:

; bat t.rs
───────┬────────────────────────────────────────────────────────────────────────
       │ File: t.rs
───────┼────────────────────────────────────────────────────────────────────────
   1   │ fn main() {
   2   │     static A: i32 = 0;
   3   │     let r: &'static _ = &A;
   4   │     dbg!(r as *const _ as usize);
   5   │ }
───────┴────────────────────────────────────────────────────────────────────────
; rustc t.rs
; ./t
[t.rs:4] r as *const _ as usize = 94587865219336
; ./t
[t.rs:4] r as *const _ as usize = 94617522643208
; ./t
[t.rs:4] r as *const _ as usize = 93992536973576

(screenshot)

[phip1611]

Rust could deduce the alignment somehow from a #[repr(align(4096))] attribute perhaps?

[RalfJung]

It is true that in this specific case, the CTFE implementation of align_offset could be made smarter to take into account the alignment of the static.

However, align_offset is also not meant for doing alignment checks, as the docs clearly indicate. If const-compatible alignment checks are something we want to provide, IMO it should be a separate function (and one that clearly documents that during CTFE, this is a conservative check since the actual address of allocations is not known yet). Being able to distinguish compile-time and run-time behavior is not necessarily a blocker, though it should be carefully considered.

Cc @rust-lang/wg-const-eval

[WaffleLapkin]

@phip1611 aligning everything to the minimum alignment wouldn't work either 😄

Consider this example:

static A: [u8; 2] = [0, 0];

assert!(
    addr_of!(A[0]).align_offset(2) == 0
    || addr_of!(A[1]).align_offset(2) == 0
);

This will pass in runtime, because either &A[0] or &A[1] must have an even address. However, if we think that every object is aligned to the minimum possible alignment (align_of::<T>()), then both &A[0] or &A[1] will have alignment = 1, so .align_offset(2) will return 1 for both (which is very unhelpful, because normally addr_of!(A[0]).align_offset(2) == 1 would tell us that A[0 + 1] is 2-aligned).

You can suggest aligning outer-most objects at minimum ([u8; 2] in this case) and then calculating alignment of other objects inside accordingly (&A[0] 1-aligned, &A[1] 2-aligned, etc), but this will, again, make runtime and compile time behaviour different, since we don't know which of &A[0] and &A[1] will get 2-aligned at runtime.

Upd: didn't see Ralfs comment when writing all of this, but similar problems would arise with "const-compatible alignment checks"

[RalfJung]

@WaffleLapkin definitely, not all cases will work. A [u8; N] static will never have a member that is const-time-aligned to more than 1. That's why I said such a check would be conservative.

The specific case @phip1611 asked about, however, would work. In fact, ptr.align_offset(X) == 0 under the smarter align_offset would behave exactly the same as the conservative const-compatible alignment check. However, a dedicated is_aligned or so might still be better since

• it is more efficient at runtime as it has to do a lot less work
• it avoids using align_offset in a way that is clearly warned against in the docs