The one thing to keep in mind when reading this article is that the malloc/free API was built when many of the issues that are identified in this article (alignment, sizing, etc.) were not issues. Until the early 80's computer memory was the limiting cost factor for most machines, and the memory models were fairly simple. Alignment to something like a page boundary was something that was completely unreasonable/unfathomable, since wasting that much RAM would have been extraordinarily wasteful.

Modern CPUs have more memory built in to L1, L2, and L3 caches than most computers had in total working memory until memory started getting cheap.

I agree with the author that has lead to some "sharp edges" for the API, but that is a normal growth pattern. I'm not saying that the API doesn't have to change, but I did want to make sure that people understand that the creators of the old APIs were not stupid, they just faced different constraints than we do now. And that led to API "shapes" that may be surprising and frustrating to use now, but made perfectly good sense at the time.

It starts already that contrary to most systems programming languages that predated C, the only way is to do math with sizeof instead of specifying types, and when arrays decay into pointers many get it wrong.

So then there is always the helpful macro, doing what should have been a language feature in first place.

They are fine for good programmers. Programmers like me need guard rails though.