4 ms·
What if I want to write a malloc that requires the size to be stored separately? (i.e. one that needs to be paired with free(ptr, length) rather than just free(
by wfunction 10y ago
What if I want to write a malloc that requires the size to be stored separately? (i.e. one that needs to be paired with free(ptr, length) rather than just free(ptr) for good performance.) Wouldn't that provide more flexibility in the challenge and be more useful (e.g. for C++'s std::allocator)?
- codr4life 10y agoThe pool reference allocator does just that internally. It prefixes each allocation with a block containing the size among other things. Either base your implementation on top of that or take the idea and run with it.
- wfunction 10y agoYou totally missed the point of my question. I was NOT asking "I have an allocator that doesn't store the buffer size; how can I use it?" I was asking, "I don't think an allocator should need to store the buffer size internally; why not formulate the challenge so that the block size doesn't need to be stored?"
- ben_bai 10y agoI would not do that. Userspace Apps have way to many ways to screw up memory managment already. Allowing them to buf=malloc(128); free(buf, 256); seems dangerous, if free can't check the size. But kernels sometimes do just that ( free(ptr, size) ), for performance reasons and because "kernel writers know what they are doing".
- codr4life 10y agoThat's a pretty nasty requirement on top of an allocator protocol; I wouldn't want to use it, or debug it for that matter, yikes. And you don't need to store the size. The slab allocator doesn't store any information except how far into the current slab it's already dished out memory.