nsCOMPtr<imgIContainer> mContainer; nsCOMArray<imgIRequest> mCursorArray; // [inherited] The specified URL values. Takes precedence over mCursor. Now doing mContainer = mCursorArray[i]; works. mContainer is null afterwards. it is rather unexpected that this compiles despite the different types. it seems to do a QI. Is this desired behaviour?

Is this specific to nsCOMArray?

(this was with gcc version 3.3.3 (SuSE Linux)) This following code also compiles: nsCOMPtr<imgIContainer> c; imgIRequest* r = ui->mCursorArray[i]; c = r; So, doesn't look specific to nsCOMArray.

From bug 264987, this code also compiled: nsIDocument* document = content->GetOwnerDoc(); nsCOMPtr<nsIDOMHTMLDocument> htmlDoc(document);

Using gcc 2.9.6 the following code does not compile: nsISupportsPrimitive p; nsCOMPtr<nsISupportsString> s = p;

Or indeed even with p correctly declared as a pointer. However it will compile with the assignment changed to a constructor.

At least, I have scrollback claiming it compiled...

Ok, so having saved my test file correctly the problem is the implicit nsQueryInterface(nsISupports*) constructor. Making it explicit fixes it. I didn't look for other constructors that needed fixing.

I couldn't find any other implicit conversions that could get abused.

Comment on attachment 163005 [details] [diff] [review] Proposed patch r=scc make sure you build a whole tree with this before you check it in, in case there has been abuse

I personally would have opted for a configure rule to/in nspr for a PR_EXPLICIT or some such, so that compilers which do not recognize explicit when built with Mozilla will still treat this correctly, but otherwise good work.

We use |explicit| all over the place, and nscore.h already handles compilers that don't support it by defining it.

Thanks for the clarification, I must have just missed those explicit cases...

Fix checked in (again... I checked it in then backed it out when I realized I hadn't built accessibility, but then bz fixed my regressions anyway, thanks!)