|
Boost : |
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-10-22 20:49:57
On 2019-10-22 23:21, Vinnie Falco via Boost wrote:
> On Tue, Oct 22, 2019 at 12:55 PM Mateusz Loskot via Boost
> <boost_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk