This is a trivial implementation that just does a or[xor] loop.
However, this pattern is used by virtually all crypto libraries and
in practice, even without assembly barriers, LLVM never turns it into
code with conditional jumps, even if one of the parameters is constant.
This has been verified to still be the case with LLVM 11.0.0.
As documented in the comment right above the finalization function,
Gimli can be used as a XOF, i.e. the output doesn't have a fixed
length.
So, allow it to be used that way, just like BLAKE3.
With the simple rule that whenever we have or will have 2 similar
functions, they should be in their own namespace.
Some of these new namespaces currently contain a single function.
This is to prepare for reduced-round versions that are likely to
be added later.
It is now possible to force linking with system linker `ld` instead
of the LLVM `lld` linker when building natively on the target. This
can be done at each stage by specifying `--system-linker-hack` flag,
and can be useful on platforms where `lld` fails to operate properly
such as macOS 11 Big Sur on ARM64 where every binary/dylib is expected
to be codesigned.
Some example invocations for each stage of compilation of Zig
toolchain:
```
cmake .. -DCMAKE_PREFIX_PATH=/path/to/llvm -DSYSTEM_LINKER_HACK=1
```
```
build/zig build test --system-linker-hack
```
```
build/zig build --prefix $(pwd)/stage2 -Denable-llvm
--system-linker-hack
```
```
build/zig build-exe hello.zig --system-linker-hack
```
Make the code easier for the optimizer to work with and introduce a fast
path for ASCII sequences.
Introduce a benchmark harness to start tracking the performance of ops
on utf8.
Do the alignment dance by ourselves whenever posix_memalign is not
available.
Don't try to use malloc as it has too many edge cases, figuring out
whether a block of memory is manually aligned by the mechanism above or
is directly coming from malloc becomes too hard to be valuable.
Comparisons with absolute epsilons are usually useful when comparing
numbers to zero, for non-zero numbers it's advised to switch to relative
epsilons instead to obtain meaningful results (check [1] for more
details).
The new API introduces approxEqAbs and approxEqRel, where the former
aliases and deprecated the old `approxEq`, allowing the user to pick the
right tool for the job.
The documentation is meant to guide the user in the choice of the
correct alternative.
[1] https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
There's no guarantee for the kernel definition to be ABI compatible with
the libc one (and vice versa).
There's also no guarantee of ABI compatibility between musl/glibc.
Fun, isn't it?
With this commit, the function tries to use more efficient syscalls, and
then falls back to non-positional reads.
The motivating use case for this change is to support something like the
following:
try io.getStdOut().writeFileAll(dest_file, .{});
We are checking that two identical, constant values, are stored at
different addresses.
But sharing a unique location doesn't look like something the compiler
wouldn't do.
It may make more sense to check that a const variable and a mutable
variable set to the same value have different addresses.
