| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
When reallocating a buffer to one with a smaller size, the number of
elements to be copied to the new buffer must not be that of the old
buffer, or the behaviour is undefined.
|
| |
|
|
|
|
|
|
|
|
| |
This allocator was not designed for reallocations, and therefore
prev->size cannot be extended because that would overlap its contents
with other data.
Because of this, the only safe way to achieve a reallocation is to
always allocate a new block, copy any existing data and free the old
block.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, tinyalloc was designed for a static heap area, failing to
allocate whenever the end boundary was reached.
Unfortunately, this design was too limiting if the same library were to
be used for WebAssembly applications, where interpreters are required to
implement the current_memory and grow_memory operators. [1]
Whereas the former returns the number of currently allocated pages by
the interpreter (64 KiB being the standard page size), the latter must
increase that number by the number of pages required by the caller, but
without exceeding the maximum limit imposed by the application
developer.
Since WebAssembly's grow_memory is usually converted to sbrk(2) by
implementations, tinyalloc now makes use of this traditional syscall to
achieve the desired effect.
[1]: https://www.w3.org/TR/2019/REC-wasm-core-1-20191205/#-hrefsyntax-instr-memorymathsfmemorygrow
|
| |
|
|
|
| |
Removing the const qualifier from a const-qualified object and modify it
is undefined behaviour.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
- Updated README
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
