Closed Bug 709628 Opened 13 years ago Closed 12 years ago

nsPrefetchNode::GetStatus truncates NS_ERROR_NOT_AVAILABLE

Categories

(Core :: DOM: Navigation, defect)

defect
Not set
normal

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.
dcamp, you have blame for this interface. What's the contract for GetStatus, and is it even used?
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.