[perfloop]

@peterbourgon

Summary

MonotonicEntropy used the entropy value to decide whether it had initialized. An all-zero value is valid, so a same-timestamp call could reseed instead of incrementing and could return the same ID. The private monotonicState now keeps initialization in a separate bool within the 80-bit value's alignment padding, preserving the full entropy range. Timestamp changes still reseed, initial-read errors still propagate, and failed increments retain the last successful value so overflow continues to be reported. No public API changes.

Conditional on successful independent uniform 80-bit reads and a same-timestamp follow-up, an initial zero selects the wrong branch with probability 2^-80 (about 1 in 1.21e24). An actual duplicate additionally requires the following read to be zero, so the two-read event is 2^-160. Other entropy readers can be non-uniform or correlated; these are not production-frequency estimates.

The changelog records these conditions.

This condition holds with this change and does not hold at 75921a7395850ea47ed4dfd832184a5a294c8fde: With Monotonic configured with inc=1 and a reader whose first 20 bytes are zero, two successful New calls at timestamp 123 return entropy zero followed by exactly one..

TestMonotonicZeroEntropy reproduces the failure at timestamps 123 and 0; the nonzero-seed, changed-timestamp, and failed-initial-read controls pass on the base, and the test passes with the fix. TestMonotonicOverflowState fails on the base and the earlier initialization-only change because a later same-timestamp call can return below the maximum; the final test passes with repeated overflow and timestamp-reseed checks.

The small public-API comparison program used for the assertion is not part of this pull request.

Test plan

The formatting check, go vet ./..., Staticcheck, and go test -race ./... passed on Linux. The macOS and Windows variants of go test -race ./... did not run in this Linux sandbox and remain target-CI work.

---

Generated by Perfloop.