Closed
Bug 226163
Opened 22 years ago
Closed 22 years ago
[FIX]Unsafe array accesses in nsTableFrame
Categories
(Core :: Layout: Tables, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla1.6final
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
()
Details
Attachments
(1 file)
|
2.20 KB,
patch
|
bernd_mozilla
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
I got asserts about this in a debug build loading
http://www.msy.com.au/Parts/PARTS_W.HTM
|
Assignee | |
Comment 1•22 years ago
|
||
Also switches two other callers to the more idiomatic form of the same thing...
|
|
Assignee | |
Comment 2•22 years ago
|
||
Comment on attachment 135889 [details] [diff] [review]
Patch
What think ye?
Attachment #135889 -
Flags: superreview?(dbaron)
Attachment #135889 -
Flags: review?(bernd_mozilla)
|
|
Assignee | |
Updated•22 years ago
|
Priority: -- → P2
Summary: Unsafe array accesses in nsTableFrame → [FIX]Unsafe array accesses in nsTableFrame
Target Milestone: --- → mozilla1.6final
Attachment #135889 -
Flags: superreview?(dbaron) → superreview+
Comment on attachment 135889 [details] [diff] [review]
Patch
yeah lets play safe here,
cellData = (row->Count() > dEndX) ? (CellData*)row->ElementAt(dEndX + 1) :
nsnull;
I wonder why this did not crash before
Attachment #135889 -
Flags: superreview?(dbaron)
Attachment #135889 -
Flags: superreview+
Attachment #135889 -
Flags: review?(bernd_mozilla)
Attachment #135889 -
Flags: review+
Attachment #135889 -
Flags: superreview?(dbaron) → superreview+
|
|
Assignee | |
Comment 4•22 years ago
|
||
> I wonder why this did not crash before
Because ElementAt() just asserts instead of crashing for now... (precisely
because of problems like this :( ).
Checked in. Thanks for the incredible review response!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•