version 0.3.3

Changes since 0.3.2:
- `b3sum` binaries are built in CI and attached to new GitHub tags.

version 0.3.2

Changes since 0.3.1:
- Fixed a compiler error on older versions of Clang,
  BLAKE3-team#79.

version 0.3.1

Changes since 0.3.0:
- The x86 build now automatically falls back to "pure" Rust intrinsics,
  under either of two possible conditions:
  1. The `cc` crate fails to invoke a C compiler at all, indicating that
     nothing of the right name (e.g. "cc" or "$CC" on Unix) is installed.
  2. The `cc` crate detects that the compiler doesn't support AVX-512
     flags, usually because it's too old.
  The end result should be that most callers successfully build the
  assembly implementations, and that callers who can't build those see a
  warning but not an error. (And note that Cargo suppresses warnings for
  non-path depencies.)

version 0.3.0

Changes since version 0.2.3:
- The optimized assembly implementations are now built by default. They
  perform better than the intrinsics implementations, and they compile
  much more quickly. Bringing the default behavior in line with reported
  benchmark figures should also simplify things for people running their
  own benchmarks. Previously this crate only built Rust intrinsics
  implementations by default, and the assembly implementations were
  gated by the (slightly confusingly named) "c" feature. Now the "c"
  feature is gone, and applications that need the old behavior can use
  the new "pure" feature. Mainly this will be applications that don't
  want to require a C compiler. Note that the `b3sum` crate previously
  activated the "c" feature by default, so its behavior hasn't changed.

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.

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.

version 0.2.2

Changes since 0.2.1 (and since c-0.2.0):
- Fix a performance issue when the caller makes multiple calls to
  update() with uneven lengths. (BLAKE3-team#69, reported by @willbryant.)

version 0.2.2

Changes since 0.2.1 (and since c-0.2.0):
- Fix a performance issue when the caller makes multiple calls to
  update() with uneven lengths. (BLAKE3-team#69, reported by @willbryant.)

version 0.2.1

Changes since 0.2.0:
- Workarounds in the assembly implementations (enabled by the "c"
  feature), to build with older compilers.

tag the first release of the C implementation, c-0.2.0

This release is motivated by a fix for a potential security
vulnerability. 421a21a fixes a bug
introduced in a1c4c4e. A truncated
pointer register led to a segfault on x86-64 under Clang 7 and 8.
Clang 9 happens to be unaffected, but the behavior is undefined in
general. See also:
BLAKE3-team#60 (comment)

The C implementation of BLAKE3 hasn't been formally packaged anywhere,
and most callers vendor code from master. This release tag is intended
to make the fix above more visible, to encourage callers to update their
vendored copies. We will continue to publish tags like this whenever
bugs in the C implementation are fixed, or if there are any incompatible
API changes.

Note that the issue above does not impact callers of the Rust `blake3`
crate. The affected file, `blake3_dispatch.c`, is not compiled by that
crate in any configuration. It does impact callers of the internal
`blake3_c_rust_bindings` crate, but that crate is not published on
crates.io and not intended for production use.