On Fri, Jun 26, 2026 at 8:30 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
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.
It's still an Awaitable that gets `co_await`'d, is my point: https://develop.capy.cpp.al/capy/7.testing/7b.mock-streams.html I really wouldn't build a parsing implementation on top of this, just for the sake that now running it in a debugger now has you essentially running a debugger in a coroutine which from what I've heard in practice is less ideal than normal code. Ideally, there should be coro underneath or need to interact with an Awaitable when implementing a parser. Localhost requires a socket, a connection, a reactor, and a running event
loop. FYI.
Yeah, but that's not really that difficult to have. This isn't to say that a mock stream isn't useful, but it's used for something higher-level than implementing HTTP, as an example.
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.
I guess, but now it doesn't really make sense to me to have two physical parts if this is just "one logical library". It sounds like Capy is just an impl detail and from what I've seen from Rainer's review, it shouldn't be public. 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.
I'll agree that "abomination" is strongly-worded and, frankly, overly-dramatic. But I think this only really reinforces that Capy shouldn't be public. The thing is, if we consider the long-term evolution of Boost, all we're going to do is continuously correct users that they shouldn't use Capy because they really want Corosio, in which case it's better if there's only Corosio to pick from. - Christian