1
0
Fork 0
mirror of https://github.com/BLAKE3-team/BLAKE3 synced 2024-05-07 09:46:16 +02:00
BLAKE3/Cargo.toml
Jack O'Connor 7caf1ad4bb version 0.2.3
Changes since version 0.2.2:
- Bug fix: Commit 13556be fixes a crash on Windows when using the SSE4.1
  assembly implementation (--features=c, set by default for b3sum). This
  is undefined behavior and therefore a potential security issue.
- b3sum now supports the --num-threads flag.
- The C API now includes a blake3_hasher_finalize_seek() function, which
  returns output from any position in the extended output stream.
- Build fix: Commit 5fad419 fixes a compiler error in the AVX-512 C
  intrinsics implementation targeting the Windows GNU ABI.
2020-03-29 01:44:00 -04:00

64 lines
2.5 KiB
INI

[package]
name = "blake3"
version = "0.2.3"
authors = ["Jack O'Connor <oconnor663@gmail.com>"]
description = "the BLAKE3 hash function"
repository = "https://github.com/BLAKE3-team/BLAKE3"
license = "CC0-1.0 OR Apache-2.0"
documentation = "https://docs.rs/blake3"
readme = "README.md"
edition = "2018"
[features]
default = ["std"]
# The "c" feature includes C and assembly SIMD implementations of the
# compression function for x86 platforms, called via FFI. (Currently it has no
# effect on other platforms.) This requires a C toolchain on the build machine.
# This is necessary for AVX-512 support, which is not yet stable in Rust, and
# the assembly implementations also perform better than those using Rust/LLVM
# intrinsics. As with the Rust implementations, these C and assembly
# implementations participate in runtime CPU feature detection, and the
# resulting binary is portable.
c = []
# Normally x86-64 builds prefer assembly implementations over C intrinsics. The
# assembly implementations perform better, perform most consistently across
# compilers, and are much faster to build. However, this feature makes the
# build use the C intrinsics implementations instead. This is mainly for
# testing purposes, and most callers will not want to use it.
c_prefer_intrinsics = []
# The NEON implementation does not participate in dynamic feature detection,
# which is currently x86-only. If "c_neon" is on, NEON support is assumed. Note
# that AArch64 always supports NEON, but support on ARMv7 varies.
c_neon = []
std = ["digest/std"]
[package.metadata.docs.rs]
# Document blake3::join::RayonJoin on docs.rs.
features = ["rayon"]
[dependencies]
arrayref = "0.3.5"
arrayvec = { version = "0.5.1", default-features = false, features = ["array-sizes-33-128"] }
constant_time_eq = "0.1.5"
# A performance note for the "rayon" feature: Multi-threading can have
# significant overhead for small inputs, particularly on x86 where individual
# cores are very fast. On the other hand, on slower platforms like ARM,
# multi-threading can be beneficial for all inputs. There's no one input size
# threshold that would work well everywhere, and this crate doesn't try to be
# clever. If you're going to enable the "rayon" feature, you should benchmark
# it for your specific use case.
rayon = { version = "1.2.1", optional = true }
cfg-if = "0.1.10"
digest = "0.8.1"
crypto-mac = "0.7.0"
[dev-dependencies]
hex = "0.4.2"
page_size = "0.4.1"
rand = "0.7.2"
rand_chacha = "0.2.1"
reference_impl = { path = "./reference_impl" }
[build-dependencies]
cc = "1.0.48"