Hacker News Reader

I don't actually agree that it's a bad api, although it certainly has shortcomings. It's a low-level api to a library that is intended to be as slim as possible.

The sorts of things the author wants are indeed valuable and important, but also belong at a higher level of abstraction. The malloc() subsystem would even be a reasonable base to implement that on top of.

View on HN

The problem described in the article is the opposite of what you say. malloc() is too high level - it hides the allocation size and simply returns a nice neat void*. This leads to implementation hacks like sneaking a capacity field into the allocation, and hiding this capacity from the user.

The proposed alternative has less magic going on.

The sorts of things the author wants cannot be built on top of malloc() and free(), that's kind of the whole point here.

I've built such things on top of malloc/free. There's nothing about them that prevents that, but it requires more than just putting some sort of wrapper around malloc() and free() calls.

Reply on news.ycombinator.com