If C is the constraint, then why are you doing generic types?
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"
See for example the last version, which is marked as "GOOD". It directly inlines all operations on the vector. The more you use it, the bigger the compiled code becomes. Need to debug it and want to set a breakpoint to vector_append? You can't. You also can't use callgrind/kcachegrind to see how fast the functions are. Yes, it's still C, but very awkward and finicky C.
My point was that this is still C, I wasn't advocating using any of it.
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...
Any compiler worth its salt be inlining those functions (provided lto is enabled) because inlining that type of tiny function is a win. Additionally, the linker can deduplicate identical functions (eg vec append for two identically sized types)
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.