Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

Parent Full thread

Nice unit test framework you have written, exactly what I have been looking for my C projects. I, too, dabble in embedded environments and can't rely on big libraries.

One question/suggestion, though. In the end of all the samples you need GREATEST_MAIN_DEFS/main()/GREATEST_MAIN_BEGIN/RUN_SUITE(xxx)/GREATEST_MAIN_END. Could this be a simple oneliner like GREATEST_MAIN(xxx)?

I do understand that this is probably required for embedded systems where you might not have a regular main(), but I would just like to write GREATEST_MAIN(xxx). Does this make sense to you? Are there use cases where it makes sense to do something else in main()?

Anyway, good stuff!

Thanks!

I use GREATEST_MAIN_BEGIN and GREATEST_MAIN_END so that people can put other things in main, around them. Also, there are often several RUN_SUITE calls, and I can't depend on vararg macros portably without also depending on C99. While there are some ways to work around that, they don't deliver enough value to justify the added complication.

Yeah, I just realized that you can't really recurse with macros without doing nasty repetition, so it is not possible to do GREATEST_MAIN(suite1, suite2, suite3, etc), not even using C99 variadic macros.

Had it been possible, it would definitely make sense to add this oneliner utility. Since it would end up being very limited, it probably doesn't.

I think it could work like this:

    SUITE_LIST(suites) {
        suite1,
        suite2,
        // ...
    };

    GREATEST_MAIN(suites);

but, again, I don't know if that's necessarily an improvement. RUN_SUITE is encapsulating saving the suite's name, optionally only running suites with names that match a certain pattern, and some other features that become tricky to implement with just a statically allocated function pointer array. I'm also trying to avoid doing anything "clever" with macros.

Reply on news.ycombinator.com