The pool reference allocator does just that internally. It prefixes each allocat...

wfunction · on Nov 15, 2016

You 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 · on Nov 15, 2016

I 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 · on Nov 15, 2016

That'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.