Closed
Bug 471018
Opened 17 years ago
Closed 17 years ago
Warning: nsFaviconService.cpp: outparam 'aHasData' not written on NS_SUCCEEDED(return value)
Categories
(Toolkit :: Places, defect)
Toolkit
Places
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
()
Details
(Keywords: fixed1.9.1)
Attachments
(1 file, 1 obsolete file)
|
2.29 KB,
patch
|
dietrich
:
review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
toolkit/components/places/src/nsFaviconService.cpp:365: outparam 'aHasData' not written on NS_SUCCEEDED(return value)
Blamed on Ehsan Akhgari <ehsan.akhgari@gmail.com>: toolkit/components/places/src/nsFaviconService.cpp:302, revision e9b859357547ec900e25f3897b4787c055038302
toolkit/components/places/src/nsFaviconService.cpp:336: outparam declared here
Blamed on Shawn Wilsher <sdwilsh@shawnwilsher.com>: toolkit/components/places/src/nsFaviconService.cpp:336, revision 005a32ae9d7a6d1161084b70518d71976abc6761
Attachment #354377 -
Flags: review?(dietrich)
Comment 1•17 years ago
|
||
the privateBrowsing check is done after looking if the icon already exists, but there's no reason to do that, so can i suggest to move up the check before looking for the icon since we're not setting an icon and this change is hwv going to overwrite the result of the check.
Comment 2•17 years ago
|
||
Comment on attachment 354377 [details] [diff] [review]
Patch
Perhaps it would be best to set the outparam to false at the beginning of the function to avoid problems like this in the future?
The "we don't care if there was data" comment in nsFaviconService::SetFaviconUrlForPage() could use fixing (even though it's not related to this patch).
Comment 3•17 years ago
|
||
Comment on attachment 354377 [details] [diff] [review]
Patch
please address comments #1 and #2.
Attachment #354377 -
Flags: review?(dietrich) → review-
| Assignee | ||
Comment 4•17 years ago
|
||
Attachment #354377 -
Attachment is obsolete: true
Attachment #355149 -
Flags: review?(dietrich)
Comment 5•17 years ago
|
||
Comment on attachment 355149 [details] [diff] [review]
Patch (v2)
you also need to move the code to get the history service :)
r=me otherwise.
Attachment #355149 -
Flags: review?(dietrich) → review+
| Assignee | ||
Comment 6•17 years ago
|
||
(In reply to comment #5)
> (From update of attachment 355149 [details] [diff] [review])
> you also need to move the code to get the history service :)
Sorry about the obvious mistake!
Landed on mozilla-central <http://hg.mozilla.org/mozilla-central/rev/0c7455076caa>
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
| Assignee | ||
Comment 7•17 years ago
|
||
Comment on attachment 355149 [details] [diff] [review]
Patch (v2)
This fixes a compiler warning. It's not an essential fix for 1.9.1, but it's not a risky one either. Nominating for approval to land on branch.
Attachment #355149 -
Flags: approval1.9.1?
Comment 8•17 years ago
|
||
Is it really a compiler warning or a real possible random return value?
| Assignee | ||
Comment 9•17 years ago
|
||
Both I guess.
Comment 10•17 years ago
|
||
Comment on attachment 355149 [details] [diff] [review]
Patch (v2)
a191=beltzner
Attachment #355149 -
Flags: approval1.9.1? → approval1.9.1+
| Assignee | ||
Comment 11•17 years ago
|
||
Keywords: fixed1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•