What does subtle.ConstantTimeCompare return, and how does it behave on unequal-length slices?

## The signature and the contract ``` func ConstantTimeCompare(x, y []byte) int ``` The documented contract is precise and worth quoting almost verbatim: it returns 1 if the two slices have equal contents and 0 otherwise; the time taken is a function of the *length* of the slices and is independent of their *contents*; and if the lengths do not match it returns 0 immediately. Three separate facts are packed into that, and interviewers probe all three. ## Fact one: it is an int, not a bool The correct test is `subtle.ConstantTimeCompare(a, b) == 1`. Go has no truthiness, so writing `if subtle.ConstantTimeCompare(a, b) { ... }` does not compile and the mistake announces itself. The dangerous mistake is subtler: `== 0` reads naturally to anyone whose reflexes come from C's `strcmp` or from `bytes.Compare`, where zero means "the same". Here zero means "different". An inverted test compiles cleanly, type-checks cleanly, and accepts exactly the inputs it was written to reject — including every length mismatch, which also returns 0. It is a bug the compiler cannot help you with, which is the argument for using `hmac.Equal` (a `bool`-returning wrapper over exactly this call) wherever you are comparing an authentication tag. Why an int at all? Because `crypto/subtle` exists to let you write code that does not branch on secret-dependent values, and a 0/1 int is the currency the rest of the package trades in. `subtle.ConstantTimeSelect(v, x, y int) int` returns `x` when `v == 1` and `y` when `v == 0`. `subtle.ConstantTimeCopy(v int, x, y []byte)` copies `y` into `x` when `v == 1` and leaves `x` alone when `v == 0`. Both take exactly the value this function produces. A `bool` return would push every caller back toward an `if` over a secret. ## Fact two: how it achieves content-independence The implementation is a plain loop: ``` var v byte for i := 0; i < len(x); i++ { v |= x[i] ^ y[i] } ``` Equal bytes XOR to zero, so `v` stays zero exactly when every pair matched. The loop always runs to the end — there is no `break`, no early `return` — and only afterwards is `v` reduced to 1 or 0 by a byte-equality helper that is itself written without a branch. That is the whole trick, and it is why the timing depends on how long the inputs are but not on where they diverge. ## Fact three: the one branch, on length Before the loop there is a genuine `if len(x) != len(y) { return 0 }`. The function is not constant-time with respect to length and does not claim to be. In practice this is fine and deliberate: for a chosen algorithm the expected size is a public constant — 32 bytes for a SHA-256-based tag, for instance — so an observer who learns that a wrong-length input was rejected quickly has learned nothing they did not already know. What matters is that you understand the boundary of the guarantee rather than assuming it covers everything. The cleaner structure, and the one to argue for in review, is to validate the length as part of parsing: decode the incoming value, reject anything whose decoded length is not the expected size as malformed input, and only then compare. The function's early return then never fires in normal operation. ## The empty-slice case Two empty slices have equal lengths, the loop body never executes, `v` stays zero, and the function returns **1**. `subtle.ConstantTimeCompare(nil, []byte{})` is 1. A `nil` slice and a zero-length non-nil slice are indistinguishable to it, because it looks only at length and contents. This matters when a missing header decodes to an empty slice and the value you are comparing against could also be empty for some reason — an uninitialised field, a helper that returned early. The comparison will report a match. Reject empty input during parsing rather than relying on the comparison to catch it. ## When to call it directly If you are comparing an authentication tag, prefer `hmac.Equal`: it is the same computation, returns a `bool`, and is impossible to invert by accident. Call `subtle.ConstantTimeCompare` directly when you need the integer to feed one of the package's other primitives, or when you are comparing something that is not a MAC and the `hmac` name would mislead a reader. The package documentation opens with a warning that is not decoration: these functions "are often useful in cryptographic code but require careful thought to use correctly". The int return is the first place that thought is required.