Hacker News Reader

Comment by gingerBill | Hacker News Reader

Loads of libc allocate. The trivial ones being malloc/calloc/free/strdup/etc, but many other things within it will also allocate like qsort. And that means you cannot change how those things allocate either.

View on HN

malloc/calloc/free is the allocator, so it makes no sense to pass it an allocator to it. qsort does not allocate. I think strdup is the only other function that allocates and it is a fairly new convenience function that would not be as convenient if you had to pass an allocator.

Many implementations of qsort do allocate using malloc.

And I know malloc/free is the allocator, but you cannot override it either.

Can you point me to a qsort that does call malloc? This is news to me as the API is designed to not require this. There is no standard way to overwrite malloc/free (which would be a limitation when using other libraries that do not make the allocator configurable), but it is often supported (e.g. malloc_hook in GNU libc) or can be done using the linker.

Glibc’s one does and it caused a security vulnerability: https://www.qualys.com/2024/01/30/qsort.txt

TBH it was also news to me, I discovered it randomly while browsing vulnerabilities… Printf also allocates, and a ton of other stdlib functions as well.

I now remember that I saw this before. But somehow I do not feel like it is a language problem when a standard library implementation allocates a temporary buffer using malloc under the hood as performance optimization.

Yeah that's my hunch as well, and replacing strdup if you absolutely have to isn't really a big problem.

Reply on news.ycombinator.com