Also, I cannot find his email address anywhere (to ask him to share it on GitHub).

Am I missing something?

https://catonmat.net/simple-ld-preload-tutorial-part-two

There's actually a better way to hook GNUs malloc:

https://www.man7.org/linux/man-pages/man3/malloc_hook.3.html

This is better because you can disable the hook inside the callback, and therefore use malloc within your malloc hook (no recursion)

But you can't use this mechanism before main()

    The use of these hook functions is not safe in multithreaded
    programs, and they are now deprecated.  From glibc 2.24 onwards,
    the __malloc_initialize_hook variable has been removed from the
    API, and from glibc 2.34 onwards, all the hook variables have been
    removed from the API.  Programmers should instead preempt calls to
    the relevant functions by defining and exporting malloc(), free(),
    realloc(), and calloc().

The global variable approach was very useful and pretty low overhead.

> EDIT (March 1, 2026): I updated the title to to clarify that this observation is specific to my environment. The original title may have implied a universal behavior, which isn’t the case. Thanks for the feedback!

It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.

Yes the syntax could have been much better.

As proven by ongoing work done by Khalil Estell, in some embedded scenarios exceptions aren't that great only due to quality of implementation, someone added the support and call it done, no effort at all to improve it.

Even Ada's Ravenscar profile does allow for exceptions in high integrity computing scenarios, in embedded systems.

Well I for one, if that would mean less "C programming with C++ compiler" that still plagues the security history to this day, great they can keep using C for that.

Reminds me of Perl's $^M: https://perldoc.perl.org/variables/$%5EM

In Perl you can "hand-manage" that. This line would allocate a 64K buffer for use in an emergency:

    $^M = 'a' x (1 << 16);

In ELF objects (i.e. on Linux) this is usually done with the "Weak" symbol binding. This is an optional flag for symbols in ELF format that let you override a symbol by providing a competing non-weak symbol, which the linker will prefer when there is a conflict. https://en.wikipedia.org/wiki/Weak_symbol

You can see the list of Weak symbols by looking for a 'W' in the output of `nm` on linux hosts.

"You can't do it, just use a library.". "Just use this library, everyone uses it.". "Even google uses this library, do you think you are better." etc.

To add another example to this, you will read that memcpy is super mega optimized on libc and you shouldn't do it yourself etc. etc. etc.

But if you just check clickhouse [1] as an example. They implemented it, it is pretty basic and they say it works well in the comments of the code.

Also you can check musl libc code etc. and it is fairly simple.

People still would argue that you used some intrinsic so it isn't portable or you just benchmarked on one case so it won't work well overall.

Well you CAN benchmark as wide as you want inside your project and have a different memcpy code per project. This kind of thing isn't as bad as people make it out to be in my opinion.

Ofc memcpy is just an example here and it applies similarly to memory allocation, io etc.

As a negative note, imo this is one of the major reasons why most software is super crappy now. Everything uses some library -> those libraries change all the time -> more breaking -> more maintenance. Similar chain happens in terms of performance because the person that wrote that library probably doesn't even know how I am using the library.

This is also why people have endless arguments about what library/tool to use while they can be learning more and more things every day.

[1] https://github.com/ClickHouse/ClickHouse/blob/master/base/gl...

Then you'll have a much better idea of when to _really_ use one that depends on intrinsics, is optimized etc, and how to benchmark them ... those are the real skills.

Unfortunately, a lot of system level knowledge like this is not found in a single place but spread over many articles/manuals/books/etc.

However, the book Advanced C and C++ Compiling: An Engineering Guide to Compiling, Linking and Libraries using C and C++ by Milan Stevanovic brings together a lot of information which you might find interesting.

I'm not really even saying this is wasteful. Maybe a static allocation would make more sense for critical exception handling code...