Andreas Schwab <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> result=a*b;
>> if (result/a!=b) { report overflow; }
>
> That won't work, since (signed integer) overflow is undefined in C. A
> compiler is allowed to optimize the condition to false.
Right, operations would hav
[EMAIL PROTECTED] (Paul Jarc) writes:
> Richard Neill <[EMAIL PROTECTED]> wrote:
>> I thought testing for overflow was quite simple?
>> Isn't it just a case of looking at the carry-bit, and seeing whether it
>> gets set?
>
> That's usually how it's done in assembly. In C, it's somewhat more
> co
Richard Neill <[EMAIL PROTECTED]> wrote:
> I thought testing for overflow was quite simple?
> Isn't it just a case of looking at the carry-bit, and seeing whether it
> gets set?
That's usually how it's done in assembly. In C, it's somewhat more
compilcated. For example:
result=a*b;
if (result/a
[EMAIL PROTECTED] (Bob Proulx) wrote:
> On some cpus the result is done one way and on others the result is
> done a different way. It is in these cases where typically POSIX
> would give up and declare it undefined behavior.
Yes, and those are exactly the cases where a message would be helpful,
Bob Proulx wrote:
Andreas Schwab wrote:
Richard Neill <[EMAIL PROTECTED]> writes:
Are you sure this isn't comparable? After all, in both cases, the user has
submitted something to which bash cannot give a sensible answer. In the
integer-overflow case, bash simply returns the wrong answer, wit
Andreas Schwab wrote:
> Richard Neill <[EMAIL PROTECTED]> writes:
> > Are you sure this isn't comparable? After all, in both cases, the user has
> > submitted something to which bash cannot give a sensible answer. In the
> > integer-overflow case, bash simply returns the wrong answer, with no
> > w
Richard Neill <[EMAIL PROTECTED]> writes:
> Are you sure this isn't comparable? After all, in both cases, the user has
> submitted something to which bash cannot give a sensible answer. In the
> integer-overflow case, bash simply returns the wrong answer, with no
> warning.
The answer is not real
Bob Proulx wrote:
Richard Neill wrote:
b)Consistent with other cases, where bash does give warnings. For example:
$ X=$((3+078))
bash: 3+078: value too great for base (error token is "078")
$ echo $?
1
That is not really a comparable case. The problem there is that the
leading zero specif
Richard Neill wrote:
> b)Consistent with other cases, where bash does give warnings. For example:
>
> $ X=$((3+078))
> bash: 3+078: value too great for base (error token is "078")
> $ echo $?
> 1
That is not really a comparable case. The problem there is that the
leading zero specifies an octal
Chet Ramey wrote:
Description:
$ echo $((40*40)
-2446744073709551616
Repeat-By:
Do some arithmetic in bash $(()).
If the numbers are out of range, the output will be wrong in
all sorts of interesting ways. No error message is given.
Fix:
Richard Neill wrote:
> Bash Version: 3.2
> Patch Level: 13
> Release Status: release
>
> Description:
> $ echo $((40*40)
> -2446744073709551616
>
> Repeat-By:
> Do some arithmetic in bash $(()).
> If the numbers are out of range, the output will be wro
Bash Version: 3.2
Patch Level: 13
Release Status: release
Description:
$ echo $((40*40)
-2446744073709551616
Repeat-By:
Do some arithmetic in bash $(()).
If the numbers are out of range, the output will be wrong in
all sorts of inte
12 matches
Mail list logo
