+++ This bug was initially created as a clone of Bug #779130 +++ Bug 779130 cleaned up a whole bunch of places in C-C where nsresult values were mixed with integer types (PRInt32 and boolean, mostly) The patches in that bug were careful not to make any semantic changes to the code, but there were many places where the existing code was almost certainly incorrect - for example, functions that returned 'false' to indicate failure, which casts to integer 0, which equals nsresult NS_OK.
Created attachment 652464 [details] [diff] [review] Return meaningful values in places touched by bug 779130 p1, p3, p4, p6, p8, p9 This doesn't cover most of the cases where existing integer values are static_cast<nsresult>; a separate patch should be built for that.
Comment on attachment 652464 [details] [diff] [review] Return meaningful values in places touched by bug 779130 p1, p3, p4, p6, p8, p9 r+ on the mime and news portion of this patch; I haven't looked at the other parts. One thing that I'm concerned about is the replacement of NS_ENSURE_SUCCESS(rv, NS_OK) with (rv, rv), as it means that some of our code could become less tolerant of faults. Given that the hostinfo.dat file in particular is not necessary for the NNTP code, it should be possible to handle not being able to read it. The fact that we check for existence immediately beforehand is a 98% solution case, but we still have a few lines in between of potential raciness, and it doesn't account for odd things like "we don't have permissions to read this" (which is probably indicative of more issues, though).
Created attachment 665970 [details] [diff] [review] Return meaningful values in places touched by bug 779130 p1, p3, p4, p6, p8, p9 - cleaned up bitrot Cleaned up bitrot due to NSPR Types and nsCAutoString changes; carrying forward r=Standard8,jcranmer