rep_hist_format_hs_stats() rounds once to the bin size, then adds noise which has been rounded to the nearest integer. This isn't ideal, because it makes the least significant bits of the noise meaningless.

This needs another fix: if we treat signal INT_MIN and INT_MAX as if they are infinite (saturating arithmetic), then the security guarantees are much easier to reason about. And the explanations are shorter, too :-)

Also, the code would be simpler, and the explanations shorter, if we added the noise when we reset the counter. I opened #23501 for this.

See my branches bug23414-029 and bug23414-028, which are security-low because the current code leaks the low bits of the noise. (And it biases the result upwards by an average of the bin size divided by 2, because it rounds first, then adds noise.)

bug23414-028 has the following changes:

the context is different due to #19130 going into 0.2.9 (but we replace the code from 0.2.8 and 0.2.9 with the same code)

there's no BUG macro in 0.2.8

the existing unit tests for round_int64_to_next_multiple_of() were based on the old implementation, which had the same upwards bias as the 0.2.9 implementation, due to the rounding function itself, rather than the order of operations

I don't think I'll have time to fix round_int64_to_next_multiple_of until the end of the week. So if anyone else wants to do it, please feel free to grab this ticket. (Or split it off into its own ticket.)