Open
Bug 958212
Opened 12 years ago
Updated 3 years ago
Rename nsMemory::(Re)Alloc to nsMemory::(Re)AllocOrAbort
Categories
(Core :: XPCOM, defect)
Tracking
()
NEW
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.
|
||
Comment 1•12 years ago
|
||
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".
|
||
Comment 2•12 years ago
|
||
> 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?
|
|
||
Comment 3•12 years ago
|
||
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.
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•