Misc fixes
- 14 Mar, 2020 1 commit
-
-
Robert Sprowson authored
During ModHandReason_ClaimAligned care is taken to start on a multiple of 32 and end on a multiple of 32 + 16 (such that the next block in the heap would be at +20 same as plain ModHandReason_Claim would do). However, during a ModHandReason_ExtendBlock there's a possibility that those criteria can't be retained, due to having to move to a larger gap elsewhere, leaving the end at an inconvenient +36. Similar allocation functions in other OS' don't guarantee to return an extended block with the same alignment, so take the position that for extends we always allocate a fresh block, copy the contents, and free the original. Shrinks are left in place. Tested with a random allocator which juggles 16 aligned allocations 50,000 times.
fe448934
-
- 12 Mar, 2020 2 commits
-
-
Robert Sprowson authored
Very much like OS_Module 12, but returns the pointer to the PW rather than its contents (or NULL if the module died during init).
15fefcd1 -
Robert Sprowson authored
Trying to dump a file larger than 2GB starting from an offset below 2GB would fail because the compare checking whether PTR#han > EXT#han accidentally set V which was taken as an error (but with R0 not really being an error block).
300d5f3c
-
