Might it be even safer to squash 'rc' down to a single pair of values (0 or 1), rather than leaving the caller with the responsibility of testing a byte for zer

Might it be even safer to squash 'rc' down to a single pair of values (0 or 1), rather than leaving the caller with the responsibility of testing a byte for zeroness safely? By leaking the 255 possible values for "not equal" to the caller, we're kind of punting the (smaller) problem, and they might do something nutty like add it to some other constant (incurring timing-leaking carries) before comparing the result against something. Of course, we're not just defending against surprises from the calling code, we're defending against compiler behavior too. We're trying to constrain its options so tightly that it has no choice but to emit a series of machine instructions that we know will run in constant time. If it weren't such a hassle, we'd write crypto_verify_bytes() in x86 assembly. It'd be lovely if our languages had a way to express these constraints directly, instead of phrasing them with artificially small types and low-level logical operations.