gdamore / c-convey Goto Github PK

We need a LICENSE.txt.

Proper documentation (perhaps a github pages site) is called for, as there are definitely some gotchas around order of execution, macro use etc.

The Windows side has to be built by hand at the moment. That's a bit unfortunate; create an NMakefile or whatever to make Windows happy.

Because of our use of static variables to hold setjmp information, it does not work to call Convey() from different call sites or multiple times. For example, two functions cannot call a 3rd function that embeds a Convey() block.

This is a major limitation. We need a way to understand the context of the caller, and either reset it, or cope. I'm not sure how to solve this at present; probably the static variable approach is just inadequate.

The test symbol name is a bit too common, and test.c is a also a bit weird.

We propose the following:

Rename all test_xxx symbols to convey_xxx

Rename T_ symbols to CONVEY_ (less likely to collide than C_.)

Rename test.c to convey.c

Merge test.h and convey.h into just convey.h - and offer a feature test ("CONVEY_NONPOLLUTE") or some such to limit namespace pollution.

Probably we should look at making all the "private" stuff in convey.c use some prefixed symbol name too, in case folks just want to #include the .c directly. (Bad idea, but some folks will want.)

Because of the crazy amount of work we do with the C preprocessor, it can be quite confusing to debug compilation errors when compiling test programs using C Convey.

I'm not sure how we can make this simple. The truth is that the CPP is an ugly beast, and its too bad we have to use it -- but this is the nature of trying to emulate lambda functions in C... When it works, it's terrifically beautiful. When it fails, its terrifically ugly.

We could implement an extended version of So that is variadic, and then define custom assertions against them, like GoConvey has. I imagine that we'd have an "assertion" type that's actually a function pointer (could be variadic), that returns a result, which would include information appropriate for logs, and which would take the arguments.

Because C is strongly typed, we'd probably need versions of these macros that understand different types. I think this would be relatively straight-forward, other than it requires C99 variadics. (Fortunately I think these are supported ~everywhere these days.)

It would be great to have Travis and AppVeyor CI coverage here -- with reports accessible from the main page.

Using variadics (which are now pretty darned universal -- Microsoft is mostly the last hold out on C99, and studio supports this C99 feature), we can give richer debugging support to the code.

We can offer a non-variadic fallback (that only takes a single argument) for folks who are stuck in the past -- enabled via CONVEY_NO_VARIADICS. That should be ~nobody.

Variadic macro support is likely to be critical for supporting richer assertions in the future.

This is really more for our own internal testing of C Convey... we'd really like to test assertion failures, and trap those failures without percolating the failed state up. What's called for here is some kind of "ExpectFailure()" or similar. This should actually invert the failure state of the current convey, so that a failure is considered "normal", although the Convey block still needs to cease execution.

This could actually include a code block, which executes in the failed context, allowing for further validation of the nature of the failure. This would greatly facilitate deep validation of our own failure handling modes.