Malloc - should not be in a system library
michael105 opened this issue · comments
Rewriting the "malloc" implementations of minilib - I again have to say, malloc shouldn't be within the C standard.
It is impossible to anticipate the usecase.
Are there going to be many small allocations, and free's, or do we have to deal with big allocations, and reallocs.
For most functions, you are able to guess, in which way they are going to be used.
Not so with malloc.
My current approaches are minimalistic.
And freed are only continuous areas, at the end.
No iterations to find free areas. Complexity 1.
It would be easily possible to e.g. keep track of free areas by a simple array.
However - when it's really impossible to do any guesses about the count of free'd areas - even this is hard to design.
I conclude, it's way better to point out to other malloc implementations. If someone writes a database, he'll have completely different weightings, than someone in the need of only a few allocations.
Very well, now I'm struggling with the focus of minilib. Obviously, a abstract implementation of malloc can fit into more cases, than a minimal one.
However, the abstraction needs more memory, as I'd like to. I started minilib with counting single bytes. I did already implement some security measures, which left the path of minimalism.
Now I do have to decide . Possibly I'm going to separate this again.