cpufeatures no longer builds for aarch64-apple-darwin

[thenextman]

I can no longer build cpufeatures for aarch64-apple-darwin

cargo build --target aarch64-apple-darwin

Compiling libc v0.2.101
Compiling cpufeatures v0.2.0 (/opt/wayk/dev/utils/cpufeatures)
error[E0433]: failed to resolve: could not find CStr in ffi
--> cpufeatures/src/aarch64.rs:124:27
|
124 | let name = core::ffi::CStr::from_bytes_with_nul(name).unwrap();
| ^^^^ could not find CStr in ffi

error: aborting due to previous error

[tarcieri]

That's unfortunate. I'm in the middle of moving and still haven't found the box containing my M1 Mac Mini so I have no way to test this right now, and AFAIK short of me manually testing on Apple hardware like that there isn't a CI solution available for macOS/aarch64 right now.

@kornelski any ideas? If we can't figure this out I'd suggest reverting #583.

[newpavlov]

We could depend on std, but I think it will be better to revert #583 and add a TODO note, something like: "migrate to CStr when it will be added to core".

@tarcieri
We probably should yank v0.2.0 after publishing v0.2.1 with a fix.

[tarcieri]

Sounds good. Will do that for now, and then we can circle back on #583.

[newpavlov]

BTW here is an issue which discusses addition of CStr to core: rust-lang/rust#46736. It does not look it will be added any time soon due to c_char being platform-dependent.

[thenextman]

FYI there exists https://crates.io/crates/cstr_core

[newpavlov]

Yes, but we certainly will not add a dependency just to check if a byte slice ends with zero. :)

[tarcieri]

Some thoughts on linking std on aarch64:

In a non-privileged context, detecting these features at runtime on aarch64 targets effectively requires asking the OS, as the CPUID-like instructions required to do so can only be executed in a kernel context.

That said, I think it would be great if we can write cpufeatures (and for that matter, the whole @RustCrypto stack) in a way that's amenable to execution in a kernel context, as kernels need cryptography too.

So personally I'm reluctant to link std if there isn't a very good reason to do so, but for ergonomics reasons if it's really important it's something we can perhaps consider on a target-by-target basis.

[tarcieri]

#583 was reverted in #597.

That change was released in v0.2.1 (#598), and v0.2.0 has been yanked.

[thenextman]

Thanks for the prompt fix!