Overflow Bug: Regression from Version 4.2.1

[Arjen Markus]

>
> Yeah, I forgot that the low-order bit is 2**0, thus the bit positions
> are, high to low, 2**31, 2**30, etc.  I stupidly was numbering 1-32,
> duh!
>
> So I should have known better: the program causing what I thought was
> in error was intentionally using the old force the overflow trick for
> a flag; thus the no range check is appropriate.
>
> But I shall make sure the person responsible knows for sure what is
> really going on because there is no such error with the Portland
> compiler as far as I know (but I'll check).
>

Hi Tom,

do not be too harsh ;). While floating-point arithmetic has been
standardised a long time ago, it seems that integer arithmetic is
not. In particular stuff like overflow is not caught routinely
(I suspect because it is actively used for all manner of trickery).
And what about those unsigned integer values you find in a language
like C?

(I remember from a long time ago writing a random number generator
where the integer numbers would indeed overflow if you did not
take care - nothing special, just a linear congruence thing).

Regards,

Arjen
of tricks to make sure