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