[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
Date: Tue, 06 Apr 2010 14:15:31 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]