Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

[Chet Ramey]

On 4/6/10 11:56 AM, Roman Rakus wrote:
> On 04/06/2010 05:32 PM, John Reiser wrote:
>>>>> Program received signal SIGFPE, Arithmetic exception.
>>>>> 0x0000000000462cd5 in exp2 () at expr.c:761
>>>>> 761 val1 /= val2;
>>>>> (gdb) print val1
>>>>> $1 = -9223372036854775808
>>>>> (gdb) print val2
>>>>> $2 = -1
>>>>>
>>>>> which is strange.
>>
>>>> Not at all. Overflow invokes undefined behaviour.
>>
>>> But why there is no overflow on 32bit system?
>>
>> No *detected* overflow.  For instance, if computing (2 ** 63)
>> gives 0 (the low-order 32 bits of the true result) and
>> does not detect the overflow (or ignores the overflow,
>> either by intention or by bug), then there is no problem
>> with computing (0 / -1).
>>
> Thanks for clarifying my words.
> So, on 32bit systems, evaluation of (2 ** 63 / -1) gives the wrong number.

It shouldn't matter whether or not the system is 32-bit.  Bash performs
arithmetic on intmax_t values, which are 64 bits on all Linux systems I
have available, at least.  I'm not sure whether the compiler or libc has
greater responsibility for manipulating 64-bit quantities.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/