Repin the two backends, which fixed a defect this suite could not see

[Sunrisepeak]

openkal-linux 0.7.1 and openkal-macos 0.6.1 correct kal_timeout_read and kal_timeout_write, which decoded a borrowed kal_stream handle with okl::unpack / okm::unpack — the decoder for an owned handle. Those backends pack an owned handle as (generation << 32) | (fd + 1), so a bare descriptor N has exactly the shape of a packed handle naming N-1 and the decode succeeded. The wait was performed upon descriptor N-1 and the transfer upon N.

Five lines here: README.md, examples/portable/mcpp.toml, kit/mcpp.toml. What a reader copies first is the line in a README, and these move with the release rather than after it.

And the suite could not have caught it

conformance/src/sections/timeout.cpp states three observations of the two operations, and each is a disjunction the defect satisfies:

observe(kind::behaviour,
        r >= 0 || r == -kal_err_again || r == -kal_err_not_supported,
        "a bounded read reports success, an expiry, or a refusal");

A bounded read of the standard input is permitted to expire, so an implementation that expires because it waited upon the wrong object is indistinguishable here from one that is right.

That is not carelessness in those lines. The section imports openkal.stream and openkal.timeout and nothing else, and there is no stream it can be sure has bytes waiting — so the honest observation is not expressible with what it has.

Both backends now carry it in their own suites, where a channel can be made: sixteen channels, each written to, each read with a bound, and the count reported rather than the first failure. Measured against the old implementation, 0 of 16 bounded reads transferred.

Whether this suite should gain the same observation is left to a change of its own. It would have to import openkal.process and be conditional on it, since that interface is optional, and folding an optional-interface question into a repin would make both harder to review.

Index entries: mcpplibs/mcpp-index#283.