For C with generic types, I think one should pick up Zig. It's exactly that, it's a low level language with manual memory management, but it allows you to do generic types like this without hacks.
If you're using C, use bloody C. Not C with weird extensions that nobody will understand. Not C attempting to gussy up into a language with a real type system. Not C with a garbage collector. etc.
I don't get why so many people use C but don't want C. This isn't 1995 where you have to shoehorn everything into the C ecosystem because everything else sucked.
Will it have IDE support for the abstraction? Will a syntax mistake explode with a non-sensical error (yes, in this instance, because you are splicing macros and a syntax mistake will splice weird)? etc.
If you want C with Generic Types, use C++. Rather than splicing unknown garbage onto C, use a subset of your C++ features and you will get full IDE support, proper template errors (okay, maybe not an improvement), proper elision and inlining, etc.
My test for whether something or not is "still C" is very simple... "Does it compile with a C compiler"
These compile. They're C. End of debate.
Whether something has IDE support is neither here nor there. When I was learning C, your IDE was "vi" and "csh"... It was still C.
As for errors, completely normal C code can spew out errors up the wazoo if you miss an errant ;, " or } (to pluck examples out of the air) somewhere important, things like "function not defined" because you were using a function later on in the file and it can no longer be parsed. Error quality does not define the language either.
Fine. My test for whether something consisting of C keywords, variable names, and symbols expected within the language as per the definition by some publicly agreed standard such as "C17", "C99" or "K&R", abhorring any non-standard extensions, other languages, or practices outside of the provided pre-processor, assembler and linker, and excluding any non-standard keywords that may or may not result in correct output, as pertaining to underlying architectural differences, is "still C" is very simple... "Does it compile with said C compiler"
People have different preferences though, so if someone has 50,000 lines of code invested in a C application, but wants to (for some reason) use generics in some way, perhaps this is their best option...
Some say it works; I've never succeeded, even on solo projects.
If I'm using C, it's probably because I'm doing something low level and garbage collector could be problematic there. If you are fine with complexity, C++ or Rust are better options. If you want a simple language, I'd suggest Zig.
On the other hand, if I don't want to deal with memory management, and still want fairly fast compiled language, I'd just go with Go. It has a much better ecosystem, because low level GC language is really mostly targeted at server components and Go excels there with implicit async everywhere.