#87 mem_seg can corrupt memory

[Brian Ruthven]

The mem_seg code can corrupt itself when splitting a range into two, and there is an allocated segment after the current range being split. If the size of the hole is just big enough for the data size requested, then the header appended may overwrite part of the existing header for the next segment.

Another manifestation of this (although there is no great impact from this particular problem) is that when the size of data requested + size of mem_seg_t header is exactly equal to the segment being split, we create a 0-sized free segment. Since this will never be used, and it will be coalesced wich an adjacent segment when it is freed, the only impact is an additional lookup when searching for free memory to allocate, so it may slow down slightly.

The obvious fix with the existing code is to skip the header if the size is within "sizeof (mem_seg_t)+1" of the next segment. It will be a slightly oversize allocoation, but since we don't enforce the mem_seg_free() caller to remember the original size, this shouldn't matter.

It may be that mem_seg needs re-writing to a better underlying format anyway, perhaps where the metadata isn't mingled with the data, so that address 0xc000 is actually usable for executables.