This didn't take into account the size of the header plus the size of
the allocation itself by virtue of `align_forward_uint`; this could
result in no change if `size` was equal to `b.alignment` because the
number is aligned, and if `actual_size` and `size` ended up being equal,
no additional space would be requested.
This meant that a block would end up being allocated on top of its
buddy's head.
Fixes#3435
And make `core:terminal` use it so that `core:log` can be imported with `-default-to-nil-allocator`,
in which the actual allocator is set up in `main()`.
Windows was tricky because of the utf-8 <> utf-16 conversion, so we use some temporary stack buffers for that purpose,
limiting the non-allocating version there to 512 utf-16 characters each for the key and environment value.
In general the value is (obviously) limited to the size of the supplied buffer, and a `.Buffer_Full` error is returned
if that buffer is insufficient. If the key is not found, the procedure returns `.Env_Var_Not_Found`.
TODO:
- Factor out buffer-backed utf8 + utf16 conversion to `core:sys/util` to more easily apply this pattern.
- Add similar `lookup_env` and `get_env` procedures to `core:os/os2`.
Fixes#5336
It has been discovered that AddressSanitizer does not keep a 1:1 mapping
of which bytes are poisoned and which are not. This can cause issues for
allocations less than 8 bytes and where addresses straddle 8-byte
boundaries.
See the following link for more information:
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#mapping
Changed the check from `bytes` to `err` for safety's sake, too.
This will prevent the potential bug of allocating non-zero memory, then
doing a zeroed resize, which will result in having garbage data in the
initial half.
The backup allocator is set at `init` and must stay the same for the
lifetime of the Scratch allocator, as this allocator is used to free all
`leaked_allocations`. Changing it could lead to a situation where the
wrong allocator is used to free a leaked allocation.
