This clouds the actual issue you're trying to get at. Using simply "int" and "unsigned int" for the example solves the problem.
I'm inclined to point the finger at "auto" here. Although this code would also not have been written if we taught to avoid relying on the "modulo" behaviour. The (I believe Google) check while processing JF's paper was that even unsigned overflow was often a bug.
Yes, I think auto is the problem. I didn't want to use auto in the example, but I was trying to get the lines to not wrap in the Tony table. As many people have noted, auto has fewer characters. Sounds like I need to get rid of auto in the example and find a way to format the code. Thanks for pointing that out.
Auto isn’t the only problem: keep in mind that on a 64-bit int system, the int32_t case is fully defined, because there is no overflow on the addition. The addition is 64-bit, and without auto, it would truncate after the addition. So on a 64-bit int system, the code will always work regardless of compiler settings, because everything that happens is well-defined.
The existence of alternate possibilities clouds the point you’re trying to make; using int and unsigned int avoids these issues entirely.
Unsigned overflow is usually a bug, but not always. Many cryptographic operations are defined in terms of wrapping arithmetic.
Melissa