Make align_up and align_down const

[josephlr]

We can't make the {VirtAddr, PhysAddr}::{align_up, align_down, is_aligned} methods const as they have a U: Into<u64> constraint.

We should consider removing this constraint for the next breaking change.

[toothbrush7777777]

Shouldn't these functions take (and return) usize rather than u64?

[phil-opp]

Looks good to me overall. Nice trick with the [(); 1] array!

One thing that is a bit unfortunate is that users on stable will get a meaningless "index out of bounds" error if they supply a non-aligned aligment. I don't think that there is any way to avoid this right now, but we should at least document this error in the method docs, e.g. as:

Panics if the alignment is not a power of two. Without the const_fn feature, the panic message will be an "index out of bounds" error in that case.

Additionally, we could add line comments before the [(); 1][!align.is_power_of_two() as usize] lines that say something like "if a panic occurs at this line it means that align was not a power of two". This way, users that look up the panic origin in the source directly see the reason for it.

[phil-opp]

@toothbrush7777777

Shouldn't these functions take (and return) usize rather than u64?

They could, but there are other places in this crate where u64 makes more sense than usize. For example, the VirtAddr type requires that wrapped addresses are canonical, which is a property that is specific to 64-bit memory addresses:

x86_64/src/addr.rs

Lines 68 to 74 in e5c202c

	pub fn try_new(addr: u64) -> Result<VirtAddr, VirtAddrNotValid> {
	match addr.get_bits(47..64) {
	0 | 0x1ffff => Ok(VirtAddr(addr)), // address is canonical
	1 => Ok(VirtAddr::new_truncate(addr)), // address needs sign extension
	other => Err(VirtAddrNotValid(other)),
	}
	}

Since conversions between u64 and usize are not really convenient (as casts risk a silent truncation; try_into can fail), we decided to use u64 as the general address type in this crate.

[josephlr]

One thing that is a bit unfortunate is that users on stable will get a meaningless "index out of bounds" error if they supply a non-aligned aligment. I don't think that there is any way to avoid this right now, but we should at least document this error in the method docs, e.g. as:

Panics if the alignment is not a power of two. Without the const_fn feature, the panic message will be an "index out of bounds" error in that case.

Docs updated (along with the GDT push method).

Additionally, we could add line comments before the [(); 1][!align.is_power_of_two() as usize] lines that say something like "if a panic occurs at this line it means that align was not a power of two". This way, users that look up the panic origin in the source directly see the reason for it.

Instead of this I just added a cosnt_assert! helper macro, which does the right thing depending on if the feature is set or not. This makes the code cleaner and self-documenting.

[phil-opp]

Good solution, thanks a lot!