[ub] P1407R0: Tell Programmers About Signed Integer Overflow Behavior
Scott Schurr
s.scott.schurr at gmail.com
Thu Jan 31 00:50:32 CET 2019
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 gmail.com
On Wed, Jan 30, 2019 at 11:18 AM Myria <myriachan at gmail.com> wrote:
> On Wed, Jan 30, 2019 at 11:08 Scott Schurr <s.scott.schurr at gmail.com>
> 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 isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ub
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/ub/attachments/20190130/f22f5131/attachment-0001.html
More information about the ub
mailing list