Re: Optimization techniques and undefined behavior

On 01/05/2019 13:53, Bart wrote:
> If you have two unknown values A and B, and need to multiply, you won't
> know if the result will overflow.


        int A := ..., B := ...;
        int C := ( A = 0 | 0 |: abs B <= maxint % abs A | A*B | error (...); 0 );


E&OE. Convert to your own favourite language. Simplifies if you
already know that A and B are strictly positive.


Before anyone asks, yes, I know that can throw an unwonted error,
eg if A = -maxint-1 and B = 1; my view is that anyone doing arithmetic
should respect "maxint" and not exploit the vagaries of 2s-complement
arithmetic. If you really want to do that, use "unsigned" [or "bits"]
values properly, rather than "int".


Of course, in the old days, compilers used to build in range
checks on array indices and overflow checks on all arithmetic. A few
still do, esp interpreters, but the God of Speed dictates that most
languages in most circumstances don't. We see the results in the huge
amount of malware that exploits that failure.


[...]
> In the example posed, you have the additional problem that the input can
> be this:
>    P5
>    389000000000000000000000000000 9200000000000000000000000000
> with both dimensions exceeding int64.


My own favourite language will throw an "on value error" exception
if you try to read those values [or any other unsuitable strings] into an
integer variable. By default, that will terminate your program with
suitable error messages/diagnostics, but you can substitute your own
"on value error" procedure if you want to print a "Don't be daft, please
type sensible values" message and try again. But it's not hard to write
equivalent code in any half-sensible language by reading that line into
a string and parsing that. If you have a string of digits starting with
a non-zero, and a string corresponding to "maxint", then you have a good
value if either (a) the input string is shorter than that for "maxint" or
(b) it is the same length and alphabetically not larger.


--
Andy Walker,
Nottingham.

Return to the comp.compilers page.
Search the comp.compilers archives again.