On Wed, Jan 30, 2019 at 11:08 Scott Schurr <s.scott.schurr_at_[hidden]> wrote:

>
>>> 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

>