Closed
Bug 540580
Opened 15 years ago
Closed 15 years ago
atomMaxIntValue and atomMinIntValue are apparently incorrect (and the latter unused)
Categories
(Tamarin Graveyard :: Virtual Machine, defect, P3)
Tamarin Graveyard
Virtual Machine
Tracking
(Not tracked)
RESOLVED
FIXED
Q3 11 - Serrano
People
(Reporter: lhansen, Assigned: lhansen)
Details
Attachments
(1 file)
2.74 KB,
patch
|
stejohns
:
review+
|
Details | Diff | Splinter Review |
atom.h:155:
#ifdef AVMPLUS_64BIT
// in 64-bit builds, integer atoms can hold a 53-bit signed value.
// (this is so that integer values can be interchanged with doubles
// with no loss of precision)
const intptr_t atomMinIntValue = -(1LL<<53);
const intptr_t atomMaxIntValue = (1LL<<53)-1;
#else
// in 32-bit builds, integer atoms can hold a 29-bit signed value.
const intptr_t atomMinIntValue = -(1L<<29);
const intptr_t atomMaxIntValue = (1L<<29)-1;
#endif
The 32-bit values are incorrect. It is correct that at atom can hold a 29-bit signed value, but the range is then -2^28..2^28-1, while 1L<<29 is 2^29.
The 64-bit values are apparently correct, but only because the double representation is sign+magnitude so we technically have a 54-bit signed number (as the values reveal).
atomMinIntValue is not used anywhere in the VM.
atomMaxIntValue is only used in ::atomIsValidIntptrValue_u(), where it is shifted in such a way that the erroneous value doesn't matter, but it's not quite clear to me why that's going on except possibly to work around the problem with the value of the constant being too large.
Are these constants used externally to the VM, ie, is this a public API?
Comment 1•15 years ago
|
||
Good catch. AFAIK these values are not used (or intended to be used) external to the VM itself. I'll do some grepping to verify. In the meantime, let's fix the values here (and add your comments expanding about how the values are derived).
Flags: flashplayer-qrb+
Priority: -- → P3
Target Milestone: --- → flash10.2
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → lhansen
Assignee | ||
Comment 2•15 years ago
|
||
Neither name is referenced in the player source code (frr-argo).
Assignee | ||
Comment 3•15 years ago
|
||
Another bug here is the shift used for 64-bit values in atomIsValidIntptrValue, it should be 10, not 8. (The function operates on untagged values, which have 54 bits of precision including the sign.)
Assignee | ||
Comment 4•15 years ago
|
||
Attachment #437966 -
Flags: review?(stejohns)
Updated•15 years ago
|
Attachment #437966 -
Flags: review?(stejohns) → review+
Assignee | ||
Comment 5•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 6•15 years ago
|
||
There is a tiny bug here in the 64-bit case because a sign+magnitude representation has a range from -(2^(n-1)-1) to 2(n-1)-1. The bug is not important because that value is not currently being used in the code, it is there for completeness.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 7•15 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Flags: flashplayer-bug+
You need to log in
before you can comment on or make changes to this bug.
Description
•