Closed
Bug 1122995
Opened 9 years ago
Closed 9 years ago
Clarify the lifetime rules applying to the permanent and non-permanent nsIATOM* members in nsAtomTable.cpp; r=froydnj
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla38
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
Details
Attachments
(1 file)
No description provided.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → ehsan
Assignee | ||
Comment 1•9 years ago
|
||
Attachment #8550799 -
Flags: review?(nfroyd)
Comment 2•9 years ago
|
||
Comment on attachment 8550799 [details] [diff] [review] Clarify the lifetime rules applying to the permanent and non-permanent nsIATOM* members in nsAtomTable.cpp Review of attachment 8550799 [details] [diff] [review]: ----------------------------------------------------------------- r=me with a suitable answer to the below question. ::: xpcom/ds/nsAtomTable.cpp @@ +171,5 @@ > } > + > +private: > + NS_IMETHOD_(MozExternalRefCountType) AddRef(); > + NS_IMETHOD_(MozExternalRefCountType) Release(); I don't know that this change really accomplishes anything, and is slightly confusing (though [class.access.virt] explicitly covers this sort of thing). What's the rationale for doing this?
Attachment #8550799 -
Flags: review?(nfroyd) → review+
Assignee | ||
Comment 3•9 years ago
|
||
Just trying to make it impossible to call AddRef/Release on concrete PermanentAtomImpl types (I know that this won't disallow virtual dispatch, but it's the best we can do here. FWIW I believe these functions _will_ be called at runtime through virtual dispatch, but their implementation makes that OK.)
Comment 4•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4a3d85dc67fc
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in
before you can comment on or make changes to this bug.
Description
•