Re: [boost] Is there interest in portable integer overflow detection, with policy based handling?

Subject: Re: [boost] Is there interest in portable integer overflow detection, with policy based handling?
From: Ben Robinson (cppmaven_at_[hidden])
Date: 2012-02-24 04:21:45

On Fri, Feb 24, 2012 at 12:31 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> IIIUC I think we agree on the goal but not on how to achieve it. I think
> verified_int should behave as the builtin types works (as much as
> possible). Let see some examples
>
>  {
>    short b=3;
>    std::cout <<"-b = "<< -b << std::endl;
>  }
>  {
>    unsigned short a=2;
>    short b=-1;
>    std::cout <<"a/b = "<< a/b << std::endl;
>  }
>  {
>    unsigned short a=2;
>    short b=-1;
>    std::cout <<"a*b = "<< a*b << std::endl;
>  }
>  {
>    unsigned short a=2;
>    short b=-3;
>    std::cout <<"a+b = "<< a+b << std::endl;
>  }
>  {
>    unsigned short a=2;
>    short b=3;
>    std::cout <<"a-b = "<< a-b << std::endl;
>  }
>  {
>    unsigned char a=240;
>    unsigned char b=240;
>    std::cout <<"a+b = "<< a+b << std::endl;
>  }
>
> The results are
>
> -b = -3
> a/b = -2
> a*b = -2
> a+b = -1
> a-b = -1
> a+b = 480
>
> As you can see the built-in types works as I was suggesting you. The
> overflow problem occurs when you assign a larger (in range) type to a
> shorter type or on some operations on the larger (signed/unsigned) integer
> type.
>
> But maybe, what verified_int is modeling is an integer type that doesn't
> converts to other verified_int types and checks for overflow. Is this what
> your library is designed for?
>
> Best,
>
> Vicente
>
> Vicente,

Thank you for your thoughtful input.  You are correct in that my
verified_int class checks for overflow while preventing any implicit
conversion of it's underlying representation.  This has certain
advantages.  Consider a small code refactor which is not expected to change
behavior (assume no compiler optimizations):

// One math operation per line:
verified_uint8_t a = 250;
uint8_t b = 10;
verified_uint8_t temp = a + b; // This will overflow
verified_uint8_t c = temp - b; // We already overflowed above

//Now two operations on the same line:
verified_uint8_t a = 250;
uint8_t b = 10;
verified_uint8_t c = a + b - b; // This will also overflow (as currently
implemented)

However, if the result of a+b can return common_type<A,B>::type which will
then subtract b, and then be implicitly converted to verified_uint8_t, the
overflow will be avoided.

But now that I think more about this, the language will cause an overflow
on assignment in the first example, and the language will avoid the
overflow in the second example due to the type of the temporary being
chosen by the compiler.

I will definitely put more thought into this.  Excellent feedback.

Thank you,

Ben Robinson

>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>