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.
