| Age | Commit message (Collapse) | Author |
|---|
|
Apart from being pretty ambiguous in general, the term "context string"
has the specific problem that it isn't clear whether it should be
describing the input or the output. In fact, it's quite important that
it describes the output, because the whole point is to domain-separate
different outputs that derive from the *same* input. To make that
clearer, rename the "context string" to the "purpose string" in
documentation.
|
|
|
|
|
|
- Visual Studio <= 2015 does not support AVX-512 either way;
- Visual Studio 2017 does not tolerate vmovd with 64-bit operands;
- Visual Studio 2019 does not care.
|
|
|
|
|
|
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/152.
|
|
Some of the SIMD code is still unformatted, so for now I'm only touching
the files that just have a couple small changes.
|
|
|
|
This should be irrelevant, but some toolchains will not accept movd with 64-bit arguments.
|
|
|
|
|
|
|
|
https://github.com/BLAKE3-team/BLAKE3/pull/24
|
|
|
|
|
|
|
|
|
|
add blake3_version(void) / BLAKE3_VERSION_STRING
|
|
related discussion here: https://github.com/BLAKE3-team/BLAKE3/issues/130
|
|
|
|
fix disabled-optimization -Wall -Werror
|
|
|
|
patch by Samuel Neves ( https://github.com/sneves )
if you tried to compile blake3_dispatch.c with
-Wall -Werror -DBLAKE3_NO_SSE2 -DBLAKE3_NO_SSE41 -DBLAKE3_NO_AVX2 -DBLAKE3_NO_AVX512
something like this would happen:
hans@xDevAd:~/projects/BLAKE3/c$ gcc -O0 -o example example.c blake3.c blake3_dispatch.c blake3_portable.c blake3_sse2_x86-64_unix.S blake3_sse41_x86-64_unix.S blake3_avx2_x86-64_unix.S blake3_avx512_x86-64_unix.S -DBLAKE3_NO_SSE2 -DBLAKE3_NO_SSE41 -DBLAKE3_NO_AVX2 -DBLAKE3_NO_AVX512 -Wall -Wextra -Wpedantic -Werror
blake3_dispatch.c: In function ‘blake3_compress_in_place’:
blake3_dispatch.c:139:26: error: unused variable ‘features’ [-Werror=unused-variable]
139 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
blake3_dispatch.c: In function ‘blake3_compress_xof’:
blake3_dispatch.c:167:26: error: unused variable ‘features’ [-Werror=unused-variable]
167 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
blake3_dispatch.c: In function ‘blake3_hash_many’:
blake3_dispatch.c:195:26: error: unused variable ‘features’ [-Werror=unused-variable]
195 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
blake3_dispatch.c: In function ‘blake3_simd_degree’:
blake3_dispatch.c:244:26: error: unused variable ‘features’ [-Werror=unused-variable]
244 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
cc1: all warnings being treated as errors
|
|
|
|
|
|
Changes since 0.3.6:
- BUGFIX: The C implementation was incorrect on big endian systems for
inputs longer than 1024 bytes. This bug affected all previous versions
of the C implementation. Little endian platforms like x86 were
unaffected. The Rust implementation was also unaffected.
@jakub-zwolakowski and @pascal-cuoq from TrustInSoft reported this
bug: https://github.com/BLAKE3-team/BLAKE3/pull/118
- BUGFIX: The C build on x86-64 was producing binaries with an
executable stack. @tristanheaven reported this bug:
https://github.com/BLAKE3-team/BLAKE3/issues/109
- @mkrupcale added optimized implementations for SSE2. This improves
performance on older x86 processors that don't support SSE4.1.
- The C implementation now exposes the
`blake3_hasher_init_derive_key_raw` function, to make it easier to
implement language bindings. Added by @k0001.
|
|
This will let us add big endian testing to CI for our C code. (We were
already doing it for our Rust code.)
This is adapted from test_vectors/cross_test.sh. It works around the
limitation that the `cross` tool can't reach parent directories. It's an
unfortunate hack, but at least it's only for testing. It might've been
less hacky to use symlinks for this somehow, but I worry that would
break things on Windows, and I don't want to have to add workarounds for
my workarounds.
|
|
Kudos to @pascal-cuoq and @jakub-zwolakowski from TrustInSoft for
catching these bugs.
Original report: https://github.com/BLAKE3-team/BLAKE3/pull/118
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/BLAKE3-team/BLAKE3/blob/master/b3sum/what_does_check_do.md
|
|
|
|
|
|
|
|
|
|
|
|
C: Add blake3_hasher_init_derive_key_len
|
|
|
|
|
|
|
|
|
|
Samuel noticed that rustc seems to assume (incorrectly?) that all i686
targets support SSE2, but it doesn't make that assumption for i586.
|
|
It will be very rare that this actually executes, but we should include
it for completeness.
|
|
This is quite hard to trigger, because SSE2 has been guaranteed for a
long time. But you could trigger it this way:
rustup target add i686-unknown-linux-musl
RUSTFLAGS="-C target-cpu=i386" cargo build --target i686-unknown-linux-musl
Note a relevant gotcha though: The `cross` tool will not forward
environment variables like RUSTFLAGS to the container by default, so if
you're testing with `cross` you'll need to use the `rustc` command to
explicitly pass the flag, as I've done here in ci.yml. (Or you could
create a `Cross.toml` file, but I don't want to commit one of those if I
can avoid it.)
|
|
|
|
|
