Hi Melissa and Hubert,

Thanks for the corrections and for the education. If an R1 of the paper is
published it will include your contributions.

Scott Schurr
S.Scott.Schurr_at_[hidden]

On Wed, Jan 30, 2019 at 11:18 AM Myria <myriachan_at_[hidden]> wrote:

> 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
>
>> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>