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
free on tlsf poisons the entire block, while alloc might only unpoison a
part of it (cause it's size is aligned up). This causes free to
potentially poison an already poisoned portion, which is a
use-after-poison.
Because this is "fine" and intended, I opted to just
@no_sanitize_address it.
This implementation doesn't allow for out-of-band allocations to be passed through, as it's not designed to
track those. Nor is it able to signal those allocations then need to be freed on the backing allocator,
as opposed to regular allocations handled for you when you `destroy` the TLSF instance.
So if we're asked for more than we're configured to grow by, we can fail with an OOM error early, without adding a new pool.
New features:
- If TLSF can't service an allocation made on it, and it's initialized with `new_pool_size` > 0, it will ask the backing allocator for additional memory.
- `estimate_pool_size` can tell you what size your initial (and `new_pool_size`) ought to be if you want to make `count` allocations of `size` and `alignment`, or in its other form, how much backing memory is needed for `count` allocations of `type` and its corresponding size and alignment.
