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
* Reorganize crypto/aes in order to separate parameters, implementations and
modes.
* Add a zero-cost abstraction over the internal representation of a block,
so that blocks can be kept in vector registers in optimized implementations.
* Add architecture-independent aesenc/aesdec/aesenclast/aesdeclast operations,
so that any AES-based primitive can be implemented, including these that don't
use the original key schedule (AES-PRF, AEGIS, MeowHash...)
* Add support for parallelization/wide blocks to take advantage of hardware
implementations.
* Align T-tables to cache lines in the software implementations to slightly
reduce side channels.
* Add an optimized implementation for modern Intel CPUs with AES-NI.
* Add new tests (AES256 key expansion).
* Reimplement the counter mode to work with any block cipher, any endianness
and to take advantage of wide blocks.
* Add benchmarks for AES.
Password hashing functions are not general-purpose KDFs, and KDFs
don't have to satisfy the same properties as a PHF.
This will allow fast KDFs such as the HKDF construction to be in a
category of their own, while clarifying what functions are suitable
for using passwords as inputs.
A simple empty main with evented-io would not quit, because some
threads were still waiting to be resumed (by the os). The os.write to
the eventfd only wakes up one thread and thus there are multiple writes
needed to wake up all the other threads.
HeapAllocator stores the pointer returned by HeapAlloc right after the
data block and, after the recent allocator refactoring, the space for
this pointer was not taken into account in the calculation of the final
block size.
Fixes#5830
