Closed Bug 662126 Opened 10 years ago Closed 10 years ago
Ex callers to ensure that a Check State is not an uninitialized PRBool
After hitting Bug 662125 in a debug build and finding the cause I found, without looking particularly hard, http://hg.mozilla.org/mozilla-central/annotate/57bedceef898/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#l1185 http://hg.mozilla.org/mozilla-central/annotate/57bedceef898/security/manager/ssl/src/nsCrypto.cpp#l2940 There may be others as well.
10 years ago
Looking at the patch for Bug 495618 would probably be a decent place to start.
Here's at least four call sites that should be fixed: - http://mxr.mozilla.org/comm-central/source/mozilla/caps/src/nsScriptSecurityManager.cpp#2803 (the last parameter of CheckConfirmDialog is passed to ConfirmEx) - http://mxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/src/nsCrypto.cpp#2941 - http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/xre/nsAppRunner.cpp#1813 - http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#1186 (Looking for more...)
This is all I could come up with. I've checked every instance of ConfirmEx in C++ code, and for each function that ends up calling ConfirmEx with the penultimate parameter being one of its own parameters, I've checked that function's own call sites.
Attachment #537608 - Flags: review?(bzbarsky)
Comment on attachment 537608 [details] [diff] [review] Fix all four call sites that I've found Looks good, thanks!
Attachment #537608 - Flags: review?(bzbarsky) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.