safe_arch

Exposes arch-specific intrinsics as safe function (via cfg).

Latest version: 1.0.0 registry icon
Maintenance score
26
Safety score
100
Popularity score
72
Check your open source dependency risks. Get immediate insight about security, stability and licensing risks.
Security
  Vulnerabilities
Version Suggest Low Medium High Critical
1.0.0 0 0 0 0 0
0.9.3 0 0 0 0 0
0.9.2 0 0 0 0 0
0.9.1 0 0 0 0 0
0.9.0 0 0 0 0 0
0.7.4 0 0 0 0 0
0.7.3 0 0 0 0 0
0.7.2 0 0 0 0 0
0.7.1 0 0 0 0 0
0.7.0 0 0 0 0 0
0.6.0 0 0 0 0 0
0.5.2 0 0 0 0 0
0.5.1 0 0 0 0 0
0.5.0 0 0 0 0 0
0.4.0 0 0 0 0 0
0.3.1 0 0 0 0 0
0.3.0 0 0 0 0 0
0.2.4 0 0 0 0 0
0.2.3 0 0 0 0 0
0.2.2 0 0 0 0 0
0.2.1 0 0 0 0 0
0.2.0 0 0 0 0 0
0.1.0 0 0 0 0 0

Stability
Latest release:

1.0.0 - This version may not be safe as it has not been updated for a long time. Find out if your coding project uses this component and get notified of any reported security vulnerabilities with Meterian-X Open Source Security Platform

Licensing

Maintain your licence declarations and avoid unwanted licences to protect your IP the way you intended.

MIT   -   MIT License

Not a wildcard

Not proprietary

OSI Compliant


Zlib   -   zlib License

Not a wildcard

Not proprietary

OSI Compliant


Apache-2.0   -   Apache License 2.0

Not a wildcard

Not proprietary

OSI Compliant



safe_arch

Exposes arch-specific intrinsics as safe function.

  • SIMD types are newtype'd (with a pub field) and given appropriate trait impls such as From, Into, Default, etc.
  • Each intrinsic gets either a function or macro so that you can safely use it as directly as possible.
    • Functions are used when all arguments are runtime arguments.
    • Macros are used when one of the arguments must be a compile time constant, because Rust doesn't let you "pass through" compile time constants.
  • There's hundreds and hundreds of intrinsics, so the names of functions and macros tend to be very long and specific because there's often many similar ways to do nearly the same thing.
    • This crate isn't really intended for "everyday users". It is intended to be an "unopinionated" middle layer crate that just provides the safety. Higher level abstractions should mostly come from some other crate that wraps over this crate.

All function and macro availability is done purely at compile time via #[cfg()] attributes on the various modules. If a CPU feature isn't enabled for the build then those functions or macros won't be available. If you'd like to determine what CPU features are available at runtime and then call different code accordingly, this crate is not for you.

See the crate docs for more details.

Additional Resources