Hacker News Reader

Comment by rini17 | Hacker News Reader

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.

View on HN

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.

Reading the replies...basically all kinds of learned helplessness :(

If you meant standards committee replies, this proposal did pass an along-the-lines vote and is now in wording committee.

My experience with the process as a first time submitter has been pretty pleasant, all things considered.

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

Respectfully, I'm sure that there's some exotic usecase that is motivating the question, but

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

> otherwise free could not work

I'm inclined to say that you just answered your own question as to why.

I was always taught that "There are parts of a binary that are there for you, the lucky high-level language programmer. And then there are other parts of the binary which are there for the compiler to clean up after the spoiled little high-level language programmer who doesn't have to write their own assembly :)"

and

"If you want to argue with the compiler, that's what `gcc -S -fverbose-asm` and $YOUR_FAVORITE_TEXT_EDITOR` is for".

But I'm curious if this advice is unrealistic for said exotic usecase.

Do tell?

I see, checking buffer boundaries for heap allocated pointers is very exotic usecase in C. /s

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

I respectfully but firmly disagree that having buffer length information available for a pointer is "extraneous".

I mean, all allocators in all languages do this, Rust C++ etc.

Also this information is of limited use to the programmer. There's no guarantee the buffer you get is going to be the size you asked for. Lots of allocators use nearest power of 2 sizes for small allocations.

For example mimalloc has separate regions by allocation size, so there's nowhere to put this info.

Reply on news.ycombinator.com