This is because wssdl is still within the boundaries of the lua grammar: the file you provide is still lua, so you have to abide by its rule.
I experimented with a key/value approach on the syntax itself (something like `{ src_port = u16 }` or `{ src_port = 16 }`), which was nicer, but the problem was that, in lua, table literals are unordered. The current approach uses the method syntax (`a:b()`) as a nice workaround, but this mandates the use of parenthesis after the type and other specifiers. This is fine though since a lot of the provided types are parameterized (e.g. `bytes(n)` which takes a number of octets)
I originally made this for an interactive index where you can query some document parts, and these parts are written in rst -- in essence, it's almost the same: rendering an arbitrary document into a string, that you may or may not manipulate later.
Man pages are their own thing -- although the end result could be the same with some aesthetic differences (man pages does not support colors per-se, though with a config you could style your titles or emphasis).
rst2ansi is a more generic document renderer, that may be used in another program to render document parts. It doesn't convert the document to an intermediate man page, nor specifically formats the document as, well, documentation.
Because C hasn't been a subset of C++ since C99, there are plenty of case where trying to do C in C++ is awkward or just not possible with standard C++:
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.
By default, if the test raises any signal or exits with anything other than 0, the test fails.
Otherwise, you can't (yet!) test if the code exits with a specific value nor simply redirect input/output, but I'll be sure to take these suggestions into account, thanks!
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.
Developer here. If you have any suggestion/criticism on the project, I'd be happy to know.
What this brings on the table compared to other frameworks is a very simple way to write tests, while giving the programmer enough liberty to do what he wants.
Criterion achieves that by implementing a xUnit structure with automatic test registration using a declarative syntax -- which means you can be very expressive with the way you declare your tests and suite in a few lines of code. The rest is handled by criterion itself and the default main it provides.
If a function may or may not return, and it is not marked for inlining, even gcc cannot infer whenever the variable exits the scope, so no.
You have to be extra careful anyways when using context switches.
I've read with great interest the source of libCello when I first saw it a few days ago on reddit, it seems like a fun experiment. Good luck with your project ! :)
This is nothing new though: all wireshark plugins must be GPL, since the API itself they rely on is GPL.