Closed
Bug 581574
Opened 15 years ago
Closed 15 years ago
remove xpconnect's dependence on the underlying type of a privatized jsval
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
People
(Reporter: luke, Assigned: luke)
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
|
4.98 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
Before fatvals, there were JSVAL_IS_INT(v) checks in xpconnect (specifically GetMember in XPCDispObject.cpp and XPCNativeMember::GetCallInfo). When the underlying type changed to be double, I introduced the temporary predicate JSVAL_IS_UNDERLYING_TYPE_OF_PRIVATE to replace the JSVAL_IS_INT check in effect and flag them so they were easy to find and remove later (now).
So, looking at the usage, it seems to guard values extract from JS_GetReservedSlot. Is the only possibly here that the value is either (1) the private we want or (2) undefined? That's my guess. Brendan? Blake?
Comment 1•15 years ago
|
||
You just want !val.isUndefined(), e.g.
/be
| Assignee | ||
Comment 2•15 years ago
|
||
Attachment #459971 -
Flags: review?(mrbkap)
Updated•15 years ago
|
Attachment #459971 -
Flags: review?(mrbkap) → review+
| Assignee | ||
Comment 3•15 years ago
|
||
Whiteboard: fixed-in-tracemonkey
Comment 4•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•