Is `safe_arch` actually any safer then `core::arch`?

[CeleritasCelery]

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?

[Lokathor]

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.

[CeleritasCelery]

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?

[Lokathor]

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.

[CeleritasCelery]

Looks like you are right. Thank you for pointing out the distinction.