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.
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?
The version we were using in CI is now getting quite old, and we
want to make sure that the code we produce is compatible with
current versions of Wasmtime.
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.
We read and write bytes directly from the state, but in the init
function, we potentially endian-swap them.
Initialize bytes in native format since we will be reading them
in native format as well later.
Also use the public interface in the "permute" test rather than an
internal interface. The state itself is not meant to be accessed directly,
even in tests.
On Darwin, according to the man pages for setrlimit(), when adjusting
max number of open fds, the reported hard max by getrlimit() is only
theoretical, while the actual maximum, set in the kernel, is hardcoded
in the header file. Therefore, the reported max has to be adjusted
as `min(OPEN_MAX, lim.max)`.
Signed-off-by: Jakub Konka <kubkon@jakubkonka.com>
This commit fixes linking issue on macOS 11 BigSur by appending
a prefix path to all lib and framework search paths known as
`-syslibroot`.
The reason this is needed is that in macOS 11, the system libraries
and frameworks are no longer readily available in the filesystem.
Instead, the new macOS ships with a built-in dynamic linker cache
of all system-provided libraries, and hence, when linking with either
`lld.ld64` or `ld64`, it is required to pass in `-syslibroot [dir]`.
The latter can usually be obtained by invoking `xcrun --show-sdk-path`.
With this commit, Zig will do this automatically when compiling natively
on macOS. However, it also provides a flag `-syslibroot` which can be
used to overwrite the automtically populated value.
To summarise, with this change, the user of Zig is not required to
generate and append their own syslibroot path. Standard invocations
such as `zig build-exe hello.zig` or `zig build` for projects will
work out of the box. The only missing bit is `zig cc` and `zig c++`
since the addition of the `-syslibroot` option would be a mismatch
between the values provided by `clang` itself and Zig's wrapper.
