Re: URL library?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-01-29 18:33:36

On Wed, Jan 29, 2020 at 8:51 AM Phil Endecott via Boost
<boost_at_[hidden]> wrote:
> The main problem I faced was that the BNF
> in the spec was wrong!

Yeah! I have noticed that the RFC sure doesn't go out of its way to
make things easy to understand.

> ...I've had a look at your parser
> and... well it's about five times as much code and much
> further removed from the BNF.

"Five times as much code" as what, a program that uses Spirit? Are you
including the Spirit source code in that figure? Anyway...

That parsing code is written in a certain style which assists with
producing meaningful code coverage reports. This makes it appear
longer than it needs to be. But not 5x longer (more like 5%).

I don't use Spirit for any libraries for a few reasons:

* Users don't like it
* It consumes too much resources to compile
* It adds a dependency
* It is less secure

With respect to dependencies, all my new libraries work without Boost
with an appropriate configuration macro defined (they will also
require C++17 instead of C++11 in this mode). A dependency on
Boost.Spirit would circumvent this.

Any security audit [1] of a version of Beast, Boost.JSON, or Boost.URL
which used Spirit would come with a massive disclaimer of security
assumptions of Spirit. By writing the parsers in a way that they don't
call into any outside code, the respective libraries can make stronger
security guarantees. Furthermore the library can assert that absent
changes in the parsing code, the security assurances are still valid.
Compare this with what might happen if a bug is introduced in a
dependency in newer version.

Thanks

[1] <https://vinniefalco.github.io/BeastAssets/Beast%20-%20Hybrid%20Application%20Assessment%202017%20-%20Assessment%20Report%20-%2020171114.pdf>