On Wednesday, July 1st, 2026 at 12:49 AM, Andrzej Krzemienski via Boost <boost@lists.boost.org> wrote:
Functions pull_from and push_to special-case on cond::eof. So do a number of examples in the docs. Why only this one? I have been told that cond::stream_truncated means "end of file, transmission ended before the handshake, may be a truncation attack, may be a safe end, judge yourself."
The pumps treats eof specially because it is the only situation in which we can finalize the sink (commit_eof). On the stream version you get success, on the sink versions if commit succeeds you get success or the ec from committing. This seems consistent.
How can users make this call when some Capy functions already discard it?
Where does Capy discard it? It should bubble up through ec.
BTW, looking at the implementation of pull_from and push_to, when an error is reported, there is no way to figure out from which stream it originated.
I think you're right about this and we should fix it.
Looking at the implementation in normalize_openssl_shutdown_read_error in Corosio, it looks like when we decide to stop a task reading an SSL stream we will not get cond::canceled, but instead we may get cond::stream_truncated. This is the only place where -- against the protocol -- we do not get the feedback that the operation was canceled as requested.
Yes, I think the mapping to stream_truncated is too aggressive. It should be addressed as well.
BTW, cond::canceled detects two things: a successfully processed cancellation request (error::canceled) and other events, possibly caused by the state of the socket at the other end.(std::errc::operation_canceled). It is not a practical condition.
cond::canceled should answer "was this canceled?," that seems like the correct usage of cond. If you want to know specifics you could check against specific error codes.