11–14 of 14 posts
This looks like some good stuff, but browsing through your code, it's honestly pretty opaque macro hell. Why so obfuscated?
Earlier quoted context omitted.
Why did you rule out using Google Test ( https://code.google.com/p/googletest )? (In case you mulled over using it.)
Google Test requires you to write your tests in C++ rather than C; so there was times I just could not use it.
Earlier quoted context omitted.
Google Test requires you to write your tests in C++ rather than C; so there was times I just could not use it.
I'm having a little trouble imagining a situation where unit tests for a C codebase are appropriate that would be stymied by having to write the tests in C++. (Maybe relying on struct layout?)
First, you'd have to wrap your header inclusions in `extern "C"` to disable mangling, then you would have to make sure you static_cast all your pointers where normally `void*` conversions would have done its job.
Furthermore, all interfaces relying on designated initializers and compound literals are broken unless you decide to compile in nonstandard GNU C++.
And there are more incompatibilities, such as using `static` or `const` in array parameter declarations or using VLA in macros which are not recognized by C++.
It's all about using the right tool for the right job, ultimately.
Earlier quoted context omitted.
Actually, I didn't know about it until now! The project uses a similar approach to mine, by parsing the DIE tree produced by dwarf, which means that it won't work if you're not compiling with -g. It also uses some very platform specific stuff, so windows & os x are out, too. Very well made nonetheless.
I think he's got OSX running now, but as you say -- it relies on some platform-specific stuff. Good to see C test frameworks doing some innovative stuff!