Closed
Bug 196217
Opened 23 years ago
Closed 13 years ago
remove nsVoidArray::ElementAt() check for an upper bounds
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
INCOMPLETE
mozilla1.5alpha
People
(Reporter: dougt, Unassigned)
Details
Attachments
(1 file)
|
1.21 KB,
patch
|
alecf
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
nsVoidArray::ElementAt() checks for an upper bound. This test should only be in
debug build. Consider the following:
nsVoidArray a;
...
int max = a.Count();
for (int index = 0; index < max; index++)
{
a.ElementAt(index);
}
I don't see any requirement of addtional bounds checking within ElementAt(). If
consumers require bounds checking in this API, there is an alternative
SafeElementAt which is availabe.
Maybe there are still customers depending on something like:
while(a.ElemenentAt(i++))
However I haven't seen any of the assertions that already exist in that code.
| Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Comment on attachment 116457 [details] [diff] [review]
removes bounds check
r/sr=alecf
Attachment #116457 -
Flags: superreview+
Attachment #116457 -
Flags: review+
| Reporter | ||
Comment 3•23 years ago
|
||
we should shoot for the 1.5a train.
Target Milestone: --- → mozilla1.5alpha
Comment 4•21 years ago
|
||
Should this be checked in?
I think we should WONTFIX this. Removing the boundscheck would surely cause
crashers in clients. It'd be better to deprecate ElementAt and move consumers
over to SafeElementAt and FastElementAt
Updated•19 years ago
|
Assignee: dougt → nobody
QA Contact: scc → xpcom
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•