[#CLJ-690] unchecked int math inconsistency with Java - Clojure JIRA

Details

Type: Defect
Status: Closed
Priority: Major
Resolution: Completed
Affects Version/s: None
Fix Version/s: Release 1.3
Component/s: None
Labels:
None

Patch:
Code and Test
Approval:
Ok

Description

Clojure 1.3.0-alpha4
user=> (-' 0 -9223372036854775808)
-9223372036854775808

More Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

0001-Handle-edge-case-in-arbitrary-precision-substraction.patch

31/Dec/10 3:42 PM

2 kB

Colin Jones

Activity

Hide

Permalink

Colin Jones added a comment - 31/Dec/10 3:42 PM

This looks like a case where, in minusP, negateP was properly promoting the negation of -9223372036854775808 (Long/MIN_VALUE) to a BigInt, but that promotion didn't propagate to addP. The Ops that got used in addP was ops(-9223372036854775808), not ops(9223372036854775808N).

The attached patch makes sure the BigInt contamination goes all the way through, and adds a few tests verifying the correct behavior.

Show

Colin Jones added a comment - 31/Dec/10 3:42 PM This looks like a case where, in minusP, negateP was properly promoting the negation of -9223372036854775808 (Long/MIN_VALUE) to a BigInt, but that promotion didn't propagate to addP. The Ops that got used in addP was ops(-9223372036854775808), not ops(9223372036854775808N). The attached patch makes sure the BigInt contamination goes all the way through, and adds a few tests verifying the correct behavior.

People

Assignee:

Stuart Halloway

Reporter:

Stuart Halloway

Vote (0)

Watch (1)

Dates

Created:

13/Dec/10 7:49 AM

Updated:

08/Apr/11 9:01 AM

Resolved:

05/Jan/11 6:45 PM