See also tree.h from freebsd [1]. If you need a generic red-black tree, this is probably your best choice in C.

[1] https://github.com/freebsd/freebsd/blob/master/sys/sys/tree....

I'm coding in C89 because I'm writing software for industrial embedded controllers. Future maintainers of this software are more likely to be electronic engineers than programmers, so "keep it simple and don't use magic" is actually extremely good advice.

That said, my code does use a couple of macros, but only to do stuff that would be very long-winded and/or impossible without, and using malloc at all is very much frowned upon: storage should either be declared ahead of time in special .var files, or on the stack.

Yeah, in general I agree with the article, the 'malloc all your memory' part is something I disagree with heavily. Outside of the fact that many malloc and calloc implementations don't particularly deal well with integer overflow[0], it introduces non-determinism into your code. MISRA C even forbids the use of dynamic memory allocation.

In fact, the environments where C shines oftentimes won't even have a dynamic allocator...

[0] Try allocating ((size_t)-1) bytes. Quite a few implementations will give you a pointer back! They'll add some space for a header, or round up the size to the nearest n-byte boundary. This problem's compounded by the fact people assume passing unsanitized input to malloc effectively sanitizes it.

This should have been shorten to "Avoid magic". This is applicable to any language, not just to C.

Magic stuff are for wizards, and most of us are not.

"Magic" becomes obvious common-sense once you understand. The overall theme of the parent comment is that we should try to understand instead of giving up, because that's what makes us learn and become better at the language.

IMHO if you want to become an expert in C and C++, you must be able to read Asm and understand what the machine is actually doing.

A very relevant article on this same idea: http://www.linusakesson.net/programming/kernighans-lever/

Magic has nothing to do with understanding assembly. Magic simply is probably undocumented piece of code (they aren't even self-documenting), that in order to understand you have to ask the author about it. There's no magic if you understand the code right away, or by looking up some reference.

> "Magic" becomes obvious common-sense once you understand.

I fully agree. Packing data into a binary array, popcount with bit fiddling, macros for generics, etc may seem "magic" to some, but they can be useful especially in performance-critical code. Once you understand these "magic", they are just some common pieces in your toolbox. C is a simple language. Learning C plus such "magic" still takes much less time than grasping the entire C++.

That is both good and bad advice. Good because yes, programmers must quickly look at others' code and be exposed to the idioms and the anti-patterns. Bad because just by looking at something the newbies don't immediately connect it with one category or another, instruction is necessary to avoid them resorting to anti-patterns (as it is ironically the case with many things Linux).

Could you give me a reason why to use macros instead of typed static inline functions?

If it's performance, where can I find something like a rationale documentation or empirical measurements of this list implementation?

I touch C only occasionally, so I'm not a guru. But I love macros. I want all languages to have macros.