Clang has some great tools I use like the various sanitizers. Static analysis sucks and almost never finds any real issues but we still use it.
If you think toxcore should use protocol buffers, feel free to port it. This is an open source project and contributions are welcome. If you do a better job than me then I will merge your contribution. We are at #tox-dev on freenode.
Being against C++ isn't inherently a bad thing. For example, Tarsnap probably won't ever use C++ code.
I can't read your PDF because of an SSL certificate error.
As has been pointed out below, there are many C bindings for Protobuf (and my argument was that using something like protobuf allows reimplementing the protocol).
From the github conversation:
silentbits said: "Nobody is going to risk using an external parser in such critical code."
jbangert replied: "What do you mean? not invented here? Google's core engineers are better (and their code gets more review, attention, etc). than anything we can produce."
silentbits said: "You have few exchange protocols: ITCH, OUTCH (NASDAQ), UTP MD, XDP (NYSE), PITCH (BATS). These protocols are in binary form and very easy to convert from/to C/C++ struct. If you produce critical software you want to have a code that you can be verified and tested. You can of course find external parsers for this, but all serious players do their own parsers. The only exception might be FPGAs implementation where whole is written in HDL (VHDL, verilog)."
Am I correct in assessing that the reason this is troubling is because the tox devs are saying "Everyone else is writing their own parsers, so we should write our own parsers too"?
I don't know. If you want to criticize a software project for writing their own parser, you'll also need to criticize Tarsnap, since they write their own too. Yet Tarsnap is basically the gold standard in native security software. So either Tarsnap is being equally crazy, or it's not so crazy after all. I wonder which one is the case?
Did Tox devs express anything on the matter? It's very hard to substantiate all of this without someone who knows the Tox project.
For example, the last reply was "The Tox protocol is very easy to parse in C which means little chance of issues." Is that from a Tox dev?
"The Tox protocol is very easy to parse in C which means little chance of issues."
Building a homegrown parser and simultaneously expecting not to have security issues, that's true confidence.
The parsing is dead simple and written in a way that mistakes are very unlikely.
Furthermore, having spent a lot of time researching parsers and how parser differentials can affect the security of systems, I suggested they use some tools, such as protocol buffers, to eliminate handwritten parsing code. The response I got was rather disheartening and downright hostile - it boiled down to the fact that protocol buffers involves C++ code which they are a priori against, without actually engaging in a factual argument (I wrote an article in the current USENIX login/ last years OSDI about parsers for binary protocols for anyone interested in background: https://www.usenix.org/system/files/conference/osdi14/osdi14... and github.com/jbangert/nail)