ow Integers Should Work

[bcs]

On 12/05/2011 01:37 PM, Don wrote:
> On 05.12.2011 18:36, bearophile wrote:
>> Manu:
>>
>>> Also, contrary to his claim, I find that wrapping is usually what I
>>> DO want in this case..
>>> It's super rare that I write any code that pushes the limits of an int
>>> (unless we're talking 8-16 bit, see my range+saturation comment before),
>>> and when I do write code that pushes the range of an int, I can't
>>> think of
>>> a time when I've not wanted to wrap as expected.
>>
>> The code you usually write seems rather unusual. I have kind of the
>> opposite situations.
>>
>> But first of all, "trapping" ints are needed to avoid bugs in normal
>> code. Some bugs are shown here:
>> http://embed.cs.utah.edu/ioc/
>
> Those mostly aren't relevant for D. C has many cases of undefined
> behaviour because it doesn't require twos-complement arithmetic. D
> doesn't have that problem.
> We still need to tidy up the semantics of << and >> to remove undefined
> behaviour. But it's hard to do much more than that.
>
> The "overflow12.pdf" paper on that site shows statistics that overflow
> is very often intentional. It's strong evidence that you *cannot* make
> signed overflow an error. Even if you could do it with zero complexity
> and zero performance impact, it would be wrong.

What is needed is a type that has *defined* overflow characteristics 
(IIRC unsigned does but there might be value in having a signed one as 
well) and, maybe, another one that traps. Undefined overflow is a bugs 
waiting to happen:

// In C
for (short i = 1; i > 0; i++);

Under GCC, no optimisation finishes in ms. With -O9, it's an endless loop.