Closed
Bug 709628
Opened 13 years ago
Closed 12 years ago
nsPrefetchNode::GetStatus truncates NS_ERROR_NOT_AVAILABLE
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
DUPLICATE
of bug 562403
People
(Reporter: n.nethercote, Unassigned)
Details
GCC tells me this:
/home/njn/moz/mi0/uriloader/prefetch/nsPrefetchService.cpp:852:24: warning: large integer implicitly truncated to unsigned type [-Woverflow]
The problem code is this:
rv = httpChannel->GetResponseStatus(&httpStatus);
if (rv == NS_ERROR_NOT_AVAILABLE) {
// Someone's calling this before we got a response... Check our
// ReadyState. If we're at RECEIVING or LOADED, then this means the
// connection errored before we got any data; return a somewhat
// sensible error code in that case.
if (mState >= nsIDOMLoadStatus::RECEIVING) {
*aStatus = NS_ERROR_NOT_AVAILABLE;
return NS_OK;
}
*aStatus = 0;
return NS_OK;
}
where |aStatus| is a PRUint16. NS_ERROR_NOT_AVAILABLE is 0x80040111, which I guess is truncated to 0x0111 which is 273. Waldo says this is an HTTP success status.
Anyway, I don't understand the consequences but it's clearly bad. It's also unclear why we return NS_OK in this error case.
Comment 1•13 years ago
|
||
dcamp, you have blame for this interface. What's the contract for GetStatus, and is it even used?
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•