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 ...
Previously if a LinearFifo was empty and discard was called
an unsigned overflow would occur. However it is safe to perform
this overflow as a bitwise & operation with 0xFFFFFFFFFFFFFF is a noop
* std.log: still print error messages in ReleaseSmall builds.
- when start code gets an error code from main, it uses std.log.err
to report the error. this resulted in a test failure because
ReleaseSmall wasn't printing `error: TheErrorCode` when an error
was returned from main. But that seems like it should keep working.
So I changed the std.log defaults. I plan to follow this up with a
proposal to change the names of and reduce the quantity of the
log levels.
* warning emitted when using -femit-h when using stage1 backend; fatal
log message when using -femit-h with self-hosted backend (because the
feature is not yet available)
* fix double `test-cli` build steps in zig's build.zig
* update docgen to use new CLI
* translate-c uses `-x c` and generates a temporary basename with a
`.h` extension. Otherwise clang reports an error.
* --show-builtin implies -fno-emit-bin
* restore the compile error for using an extern "c" function without
putting -lc on the build line. we have to know about the libc
dependency up front.
* Fix ReleaseFast and ReleaseSmall getting swapped when passing the
value to the stage1 backend.
* correct the zig0 CLI usage text.
* update test harness code to the new CLI.
These APIs allow one to write code that is agnostic of whether it is
using an ArrayHashMap or a HashMap, which can be valuable. Specify
intent precisely: if you only need the count of the items, it makes
sense to have a function for that.
