My biggest bewilderment with C is that malloc has to store the buffer size otherwise free could not work...but nobody in decades thought to make this information accessible to the programmer! If you want to keep track of buffer bounds in C, you have to do it artisanally. Despite it's, in most implementations, stored right there next to the data and thus in L1 cache already.

> nobody in decades thought to make this information accessible to the programmer!

Obviously this is untrue. Under GNU we have malloc_usable_size(3). What's true is that it never became standardized, but standards for just about anything in C are very bare, so it's not too surprising.

Not nobody! This proposal discusses some of the tradeoffs with exposing the size given a pointer, while proposing a different way to give the true buffer size:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3899.pdf

Many fast allocators do not store the size next to the allocation, and may not store the requested size at all. This has the advantage that freeing a large allocation does not fault in cold pages with a write, as well as reducing allocator memory overhead.

> but nobody in decades thought to make this information accessible to the programmer

Isn’t this implementation details, and an information already available caller side. It would be like returning the filename for a file handle. The more extraneous details in an API, the less flexible it is.