Is `safe_arch` actually any safer then `core::arch`?
Closed this issue · 4 comments
As I understand it, the reason core::arch
intrinsics are unsafe is because running an unsupported instruction on a CPU is UB. Therefore it is up to crate authors to make sure that doesn't happen. With the exception of things like safe_arch::load_m128
which is safer because it takes a reference instead of a pointer, I don't see anything this crate is doing to make the intrinsics safe. It is mentioned in the docs that this crate uses #[cfg(...)]
to achieve safety, but the exports from core::arch
are already cfg
'ed.
Put another way, other then the pointer wrapping functions, is there any UB I could trigger with core::arch
that using safe_arch
would protect me from?
core::arch
uses cfg per arch
safe_arch
uses cfg per cpu feature
This means that the safe_arch
functions won't exist unless the CPU feature is enabled within the build at compile time. That's why they perform no additional runtime checking, all checking happens at build time.
When I look in the source for core::arch
I see the functions contain attributes like this
#[target_feature(enable = "avx2")]
fn ....
which as I understand it means it will not define that function if the target feature in unavailable. Which sounds like "cfg per cpu feature". How are they different?
Target Feature Enable forces the function to be compiled as if that feature is available even when that feature is not part of the base feature set of the overall build. It doesn't select if the function is available or not like cfg
does.
Looks like you are right. Thank you for pointing out the distinction.