This was causing the Dir.readLink test to fail for me locally with error.Unexpected NTSTATUS=0xc0000022. Not sure if PRIVILEGE_NOT_HELD is actually possible or not.
I want to take the design of this in a different direction. I think this
abstraction is too high level. I want to start bottom-up.
std-lib-orphanage commit 179ae67d61455758d71037434704fd4a17a635a9
This is convenient for debugging purposes, as well as simplifying the
caching system since executable basenames will not conflict with their
corresponding object files.
https://github.com/ziglang/std-lib-orphanage/
This code is not used by anything else in the standard library or by the
compiler or any of its tools and therefore it's a great candidate
to be maintained by a third party.
* change some {} to be {s} to gain type safety
* fix libraries being libfoo.lib instead of foo.lib for COFF
* when linking mingw-w64, add the "always link" libs so that we
generate DLL import .lib files for them as the linker code relies on.
* COFF LLD linker does not support -r so we do a file copy as an
alternative to the -r thing that ELF linking does.
I will file an issue for the corresponding TODO upon merging this
branch, to look into an optimization that possibly elides this copy
when the source and destination are both cache directories.
* add a CLI error message when trying to link multiple objects into one
and using COFF object format.
Showcase that Zig can be a great option for high performance cryptography.
The AEGIS family of authenticated encryption algorithms was selected for
high-performance applications in the final portfolio of the CAESAR
competition.
They reuse the AES core function, but are substantially faster than the
CCM, GCM and OCB modes while offering a high level of security.
AEGIS algorithms are especially fast on CPUs with built-in AES support, and
the 128L variant fully takes advantage of the pipeline in modern Intel CPUs.
Performance of the Zig implementation is on par with libsodium.
Comment reproduced here:
If we're linking libc, some naughty applications may have
registered atexit handlers which we really do not want to
run in the fork child. I caught LLVM doing this and it
caused a deadlock instead of doing an exit syscall. In
the words of Avril Lavigne, "Why'd you have to go and
make things so complicated?"
Before:
gimli-hash: 120 MiB/s
gimli-aead: 130 MiB/s
After:
gimli-hash: 195 MiB/s
gimli-aead: 208 MiB/s
Also fixes in-place decryption by the way.
If the input & output buffers were the same, decryption used to fail.
Return on decryption error in the benchmark to detect similar issues
in future AEADs even in non release-fast mode.
stage1 was unable to parse ranges whose starting point was written in
binary/octal as the first dot in '...' was incorrectly interpreted as
decimal point.
stage2 forgot to reset the literal type to IntegerLiteral when it
discovered the dot was not a decimal point.
I've only stumbled across this bug because zig fmt keeps formatting the
ranges without any space around the ...
