Snaipe

This means that if you distribute your dissector, you have to make your sources available.

This is nothing new though: all wireshark plugins must be GPL, since the API itself they rely on is GPL.

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.

Author here.

This software is still in alpha, and lacks in both handling some reST features and style extensibility, but is still pretty much functional.

I made this for another project of mine where I needed to render some document parts over the terminal, and decided to give reST a go.

As always, suggestions are welcome.

Author here. This was fun to make, although I'm sure this algorithm is absolutely nothing new.

An implementation of this for rendering tables as rst-style ascii is available here: https://github.com/Snaipe/table2ascii

As always, suggestions are welcome.

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.

Macros are used to handle platform specific details, for the most part. I don't think it's that opaque, but then again I might be biased.

Google Test requires you to write your tests in C++ rather than C; so there was times I just could not use it.

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!

Both will be implemented quite soon.

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.

Developer here.

I made this unit testing framework out of frustrations I had (and still have) with other C frameworks like CUnit or Check.

I wanted to make something much more simple, yet as powerful, and I think (and hope) I nailed it pretty much after a few months of work.

If you have any questions or suggestions, feel free to ask :)

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.

Samples: https://github.com/Snaipe/Criterion/blob/bleeding/samples

Documentation: http://criterion.readthedocs.org/en/latest/

Developer here. I'll be happy to answer or listen to any question/criticism.

The library is currently supported on Linux and Mac OS X.

Developer here, I would be happy to answer any question that you have. If you have any suggestions/criticism, I would gladly hear it!

Developer here, if anyone has suggestions/criticism, I would be glad to listen.

AMA.

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.

Not tested, but since longjmp has __attribute__ ((noreturn)), it should.

I pretty much explain all that in the article[1], but here is the gist of it:

* I implemented smalloc and sfree to respectively allocate and deallocate a memory block with prepended metadata

* I use a GNU variable attribute called cleanup to run sfree when the variable goes out of scope

* I made some macros to have some syntactic sugar on top of that

[1] - http://snaipe.me/c/c-smart-pointers/