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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-02-24 03:31:37

Le 24/02/12 05:42, Ben Robinson a écrit :
> On Thu, Feb 23, 2012 at 5:59 AM, Vicente J. Botet Escriba<
> vicente.botet_at_[hidden]>  wrote:I would expect the result type of dividing
> unsigned verified_int and signed verified_int to be signed verified_int.
> Couldn't this help to avoid the overflow on operator/()?
>
>> Of course, if the user assigns a signed to an unsigned, overflow must be
>> checked.
>> I would also prefer that there is no implicit conversion from signed to
>> unsigned verified_int. A specific cast could be used for this purpose.
>>
>> unary minus operator on unsigned verified_int could also result on a
>> signed verified_int.
>>
>> I agree with you on preventing implicit conversions.  As far as the return
> types of math operations, the resulting type is always that of the LHS.
> The leftmost type in a sequence of binary math operations is used for the
> entire computation, as it is processed left to right.
Note that process and type are different things. The type of T+U can be 
common_type<T,U>::type.
>
> My philosophy on verified_int, is that overflow should be detected, not
> avoided.  If the author needs a larger data type, then this library will
> catch that overflow, and the data types can be increased to accomodate the
> necessary ranges.  I do mostly embedded development, and many data types
> are chosen to minimize space.

In general, the space is taken by the variables, the temporaries do no 
count so much.
> This library was designed to add overflow
> detection only, and not implicitly convert data types.  That way, once
> overflow was proven to not exist in a code base, the verified_int could be
> replaced with the underlying types via some typedefs, and the run-time cost
> is completely eliminated.  If verified_int starts doing more than just
> checking, than changing to the underlying types would change the system's
> behavior, an undersirable effect.  We agree on this point I believe.
>
>
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