Open Bug 958212 Opened 8 years ago Updated 8 years ago

Rename nsMemory::(Re)Alloc to nsMemory::(Re)AllocOrAbort

Categories

(Core :: XPCOM, defect)

24 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: jdm, Unassigned)

Details

I never remember whether the nsMemory allocators are infallible or not whenever I come across them. I think it would be worth making this behaviour explicit.
If we're going to touch them at all, we should remove them. They are just there for source-compat reasons.

The real question is what to do about NS_Alloc. And I suspect the answer is probably "nothing".
> The real question is what to do about NS_Alloc. And I suspect the answer is
> probably "nothing".

Well, it might be nice to replace all its usage with direct calls to moz_xmalloc afaict that's what it always does, if your in libxul directly otherwise the stand alone glue is the only other impl and that seems to call into the frozen functions?
The point of NS_Alloc is to be the XPCOM shared allocator for string buffers, XPCOM outparam arrays, etc. Yes, it does call directly into moz_xmalloc, but that's an implementation detail that has changed and might again. I don't think we should wholesale replace NS_Alloc with something else.
You need to log in before you can comment on or make changes to this bug.