NS_Alloc became infallible by bug 680556. Contents should not be able to crash the browser.
> NS_Alloc became infallible by bug 680556. So how does one do a fallible allocation guaranteed to come from the heap NS_Free frees from?
NS_Alloc used to use moz_malloc, and now it uses moz_xmalloc, so moz_malloc should be a fine choice.
This is true if you're guaranteed to be in the same library as nsMemoryImpl.cpp. Is that true for all NS_Alloc users? I sort of doubt it... If you're not in the same library, then I'm not entirely sure a direct moz_malloc call is equivalent. For XHR, they're possibly both in libxul right now, of course, so it might be ok. What about other consumers?
At least js is not inside the same library on Windows (until js has been folded into libxul again). https://mxr.mozilla.org/mozilla-central/search?string=NS_Alloc&find=%2Fjs%2F&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central
JS is irrelevant since it doesn't use XPCOM functions. Within gecko code they are definitely equivalent. We could certainly add a NS_FallibleAlloc but I'm not sure that's necessary.
So, what about removing NS_Alloc? Is it still required for libxul era?
Support for sendAsBinary was removed in bug 853162, so this bug is no longer valid.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.