- Introduce new `Path` type and an array of build paths on the build context.
- Resolve input and output paths/files early (before parsing).
- Error early if inputs are missing or outputs are directories.
- Plumb new file path generation into linker stage instead of its adhoc method.
TODO:
- Remove more adhoc file path generation in parser and linker stage.
- Make intermediate object file generation use new path system.
- Round out and robustify Path helper functions.
Additionally:
- Firm up PNG loader with some additional checks.
- Add helper functions to `core:image` to expand grayscale to RGB(A), and so on.
TODO: Possibly replace PNG's post-processing steps with calls to the new helper functions.
`_DIGIT_NAILS` is defined as 4, meaning that we use 60 out of every 64 bits.
We can use as few as 1 nail, using 63 bits out of every 64, and all tests will still pass.
However, it needs more testing to see if that's a worthwhile change to make.
For the tests to work properly when changing the nails, Python needs to know about it as well.
In addition, compile the big math code with `-o:speed` going forward.
Does `make()` with `count + 1` and appends final component (note a
trailing separator will now result in an empty final component)
Adds test "tests/core/path/filepath/test_core_filepath.odin"
trunc_f16/32/64 in "math.odin" (~ typos on expressions)
Fix classify_f16 Inf test (would fail for subnormal 0h0001)
by changing multiplier 0.5 -> 0.25
Add some useful consts to "math.odin" (INF_F16 etc)
Add comment to "demo.odin" mentioning that -0.0 must be used
to specify negative zero
This adds `rand_bytes(dst: []byte)` which fills the destination buffer
with entropy from the cryptographic random number generator. This takes
the "simple is best" approach and just directly returns the OS CSPRNG
output instead of doing anything fancy (a la OpenBSD's arc4random).
This package implements the ChaCha20 stream cipher as specified in
RFC 8439, and the somewhat non-standard XChaCha20 variant that supports
a 192-bit nonce.
While an IETF draft for XChaCha20 standardization exists,
implementations that pre-date the draft use a 64-bit counter, instead of
the IETF-style 32-bit one. This implementation opts for the latter as
compatibility with libsodium is more important than compatibility with
an expired IETF draft.
