On Sunday, 16 January 2022 at 15:32:41 UTC, Salih Dincer wrote:
If count is not equal to 8 I get weird results! The reason of
course, is the free():
// [93947717336544, 1, 2, 3, 4, 5, 6]
I wonder if you're seeing something you're not suppose to as part
of the internals; Typically malloc for 16bit allocation to my
understanding worked a little different, where you had 2 bytes
BEFORE the memory block which specified a size, and if it was
negative then it was a size of free memory (*This allowed a 64k
block to have multiple allocations and de-allocations*). So you
might have: **64, [64 bytes of data], -1024, [1024 unallocated
memory],32,[32 bytes of allocated data, etc]**. in the above if
you deallocated the 64 byte block, it would just become -1090
(*merging the next free block, 1024+64+2*). This would also
explain why double freeing would break since it would be
referring to free size and throw a fit, or it was no longer a
length malloc/free could use.
Also malloc if it returns anything guarantees at least that size,
you might ask for 7 bytes but get 16 and the others is just
ignored.
Is this how the 32/64bit malloc/free work? Not sure, it wouldn't
be unreal for Java and others to pre-allocate say a megabyte and
then quickly give/manage a smaller block and extending or getting
another block later.
Though I'm sure others here have given better/more exact on
internals or how allocation works in D.
