[libc] Properly handle max malloc (=32764 bytes) in v7malloc #2110
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
More v7malloc fixes paying proper attention to signed vs unsigned compares, 16-bit multiply overflow and address wrapping, all used within the allocation routine. This version properly handles the maximum allocation possible given it's
sbrk
implementation and 16-bit int, which ismalloc(32764)
.Compiling with
-Wextra
also produced more warnings which are now fixed.V7malloc is currently not used within any applications except
fm
, where it was required due to our current malloc fragmenting the heap. I am considering replacing the libc malloc with v7malloc. There is considerable difference in heap usage and fragmentation between malloc and realloc between the two implementations. Actual allocation speed performance is considered as less important than better heap management for our smaller address space.