On Fri, Jun 26, 2026 at 8:07 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
It's worth noting for the review managers and other readers that it's typically considered a strong anti-pattern to tie security-critical functionality like parsing network bytes to a scheduler.
It isn't clear what distinguishing between "review managers" from "other readers" buys us but ok. I'm interested in seeing where I can read more on the typical anti-patterns for security-critical functionality. A byte-oriented stream is an interface, with read_some() in Capy. The parser calls read_some() and gets bytes. It does not know what backs the stream. It does not know if a scheduler exists. You can back the stream with a span<char> holding fuzzer output and have no scheduler at all. And no network dependency. This is how libraries like Botan, rustls, etc. work and is even how Beast
works underneath it all.
Beast is my library. The HTTP parser I linked earlier uses the same architecture, built on Capy. The pattern is praised alongside the claim that Capy doesn't use it. Capy uses it. Byte-oriented streams may be somewhat nice but tbqh, they're isomorphic to just
generating localhost traffic anyway
Localhost requires a socket, a connection, a reactor, and a running event loop. FYI.
You propose two libraries but then it's wrong when only the foundational one gets reviewed?
The review call described one logical library in two physical parts. The purpose of the split was explained in the submission. Reviewing Capy for what Capy claims to do is valid. Reviewing Capy for what Corosio claims to do is a category error.
It either stands up on its own or it doesn't.
A false dilemma? Capy stands up fine for its stated scope. The complaint is that Capy doesn't have the scope of Corosio. I'm not saying that's an abomination. I'm not calling it a specious argument. I'm not even saying it's not a rigorous review. It is a cope error. Best