Free memory with explicit size
I'm looking for malloc/free-like APIs in mainstream OSs that allow me to specify an explicit size during both allocation and de-allocation.
I'm not aware of any.
What I hope to gain by this, is that the runtime might spend less memory on bookkeeping, when the allocated size is already available in the program.
This idea certainly can work, but there are a couple of drawbacks:
you have to partition allocation regions between objects whose allocated size is tracked by the caller, and objects where the allocator still needs to record that itself.
This increases complexity and potentially memory fragmentation.
you have to allocate exactly the size the program requests.
That is, a normal allocator could decide to return a 96-byte chunk for a 64-byte request, because it's just been freed, is hot on cache, and splitting and re-coalescing chunks smaller than 64 bytes is not deemed worthwhile.
Your allocator can't do that, in general (it is limited to rounding up to the next aligned chunk size).
Of course, there are plenty of specialized allocators that manage these tradeoffs explicitly.
Using or writing these is a perfectly normal thing to do when the general-purpose allocator isn't a good fit for your allocation patterns. But, they're generally not provided by the language or OS, because they're not general-purpose. They're provided by libraries (or by yourself).
Examples:
You allocate and free a lot of objects with a previously-known fixed size.
Write an object pool allocator for them. It doesn't need to track the allocation size, because it's always the same (often a template parameter). You don't need to explicitly track it in your code either, because it's implied by the type.
Variable-sized allocations of trivial objects all with the same lifetime (eg, lots of char buffers).
Write an arena allocator. It doesn't need to track individual allocation sizes, because you reset the entire allocator instead of freeing and re-allocating individual objects. You never explicitly delete the allocate objects, because they're trivial anyway.
NB. If you choose to integrate your allocator using new/delete overloads (and think it will benefit from the explicit size parameter) you absolutely can use the ones Maxim points out, with the following caveat:
... [explicit size overloads will be] Called instead of [the default overloads] if a user-defined replacement is provided, except that it's unspecified [which] is called when deleting objects of incomplete type and arrays of non-class and trivially-destructible class types.