Correctness bug in TDPL

[Andrei Alexandrescu]

On 5/13/11 5:29 PM, Timon Gehr wrote:
> Andrei Alexandrescu wrote:
>> On 5/13/11 1:01 PM, Timon Gehr wrote:
>>>> On 5/13/11 3:25 AM, Timon Gehr wrote:
>>>>> On p368 the CheckedInt struct does not check for overflow in the unary minus
>>>>> operator.
>>>>
>>>> Unary minus never overflows. That being said, there is the oddity that
>>>> -x is x when x == int.min. Even in that case there is no loss of
>>>> information.
>>>>
>>>> Andrei
>>>
>>> This behavior is caused by _overflow_ when the error condition that is checked in
>>> ++ is overflow:
>>>
>>> auto x=CheckedInt(int.min);
>>> x=-x; //passes
>>>
>>> x=~x;
>>> x++;//throws
>>
>> Not sure I understand the point here. I do agree that this may be
>> confusing and also that it's reasonable to check against int.min in
>> unary minus.
>
> In two's complement, -x is the same as ~x+1. The implementation in TDPL says one
> is correct and the other is wrong on int.min.

Now I understand. Thanks for clarifying. I updated the errata with 
credit and with a reference to this discussion:

http://erdani.com/tdpl/errata

> My understanding is that something that claims to be a CheckedInt has exactly two
> options on every operation:
>
> 1. Behave like a pure whole number, without any strange corner cases.
> 2. Throw an exception.
>
> struct CheckedInt in TDPL does not guarantee that.
> This means it basically gives no reasonable guarantee. You may disagree on this
> but in my eyes it is a serious bug.
>
>>
>>> Also, the statement that there is no loss of information is just wrong:
>>>
>>> scanf("%d %d %d",&n_,&m_);
>>> auto n=CheckedInt!int(n_),m=CheckedInt!int(m_);
>>> enforce(n>0&&   m<0, "provide meaningful input!");
>>> foreach(i;0..n) m=-m;
>>> writeln(n," is"~(m<0?"odd":"even")); //disaster strikes!
>>
>> Depends on how one defines "information". I meant it simply as state
>> available to the program.
>
> Okay. But I think this is not really applicable to CheckedInt. By this definition
> the fact that int.max+1==int.min is just another oddity (when inspected nearer it
> is even just the same oddity), not overflow that loses information. TDPL checks
> for that though.
>
>>
>>
>> Andrei
>
> But it is of course up to you if you consider this a worthy addition to some
> future version of TDPL.

It definitely is. I appreciate you followed through and explained the 
matter to me.

> Timon
>
>
> OT: I got one of those without an author on it. =) How many are there of those?
> BTW, it is one of the best reads I've had!

Thanks very much! There were like 1830 copies without an author's name 
on the cover, they are now getting hard to find.


Andrei