Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk