On 2019-10-22 23:21, Vinnie Falco via Boost wrote:
On Tue, Oct 22, 2019 at 12:55 PM Mateusz Loskot via Boost
wrote: I'd consider covering the thing with https://google.github.io/oss-fuzz/ instead.
My strategy for ensuring correctness is two-fold. First, as with Beast, it will be reviewed by an external company (they will do the fuzzing). Second, are the special tests I write so that I have confidence everything works.
[snip]
With these techniques I achieve close to 100% code coverage and very high confidence that every path through the parser is correct. After a bunch of testing (which consists of telling users it is "ready" and seeing what they report back) I submit it to the external code auditing company to get a report. After fixing any issues they raise in the report, my strategy changes: touch the code as little as possible. If this code used an external dependency, and that upstream code changed, then transitively it means my code changed - for this reason I avoid using external code like Spirit (or regex) even if it means I have to duplicate stuff.
Although I appreciate that you achieve a great degree of code stability with your approach, I find it counter-productive since it encourages constantly reinventing the wheel and monolithic design. Imagine if every library in Boost had its own copy of e.g. shared_ptr. No matter how well tested and reliable each copy is, that would be a nightmare for users. IMO, we should reuse the well designed, reviewed and tested code that we already have (and Boost.Spirit is an example of such). Otherwise all that work someone put in that code was done in vain.