Closed
Bug 1499545
Opened 6 years ago
Closed 6 years ago
WorkerPrivate double-initializes mMainThreadEventTarget
Categories
(Core :: DOM: Workers, enhancement, P2)
Core
DOM: Workers
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: jimb, Assigned: jimb)
References
Details
Attachments
(1 file)
This is a very minor cleanup, but:
WorkerPrivate::mMainThreadEventTarget is initialized to GetMainThreadEventTarget in the member initializer list:
, mMainThreadEventTarget(GetMainThreadEventTarget())
but then is definitely initialized by every path through the function body. It seems like it would be better to initialize it to nullptr, to ensure a crash if the body fails to attend to it. (This means it could be omitted from the member initialized list altogether, since nsCOMPtr's default constructor initializes the pointer to nullptr.)
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → jimb
Comment 2•6 years ago
|
||
Sorry to butt in, but wouldn't it be better to write an initialization function for that member and call it in the initialization list? That way we get static correctness guarantees instead of random crashes. (As a plus, it disentangles the various initialization steps from each other.)
Priority: -- → P2
Pushed by jblandy@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bbff80c1200f
Don't double-initialize WorkerPrivate::mMainThreadEventTarget. r=baku
Comment 4•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Updated•6 years ago
|
Flags: qe-verify-
You need to log in
before you can comment on or make changes to this bug.
Description
•