We don't check against a hard limit but TOT will no longer crash or
overwrite memory (try it). We now detect the allocation failure. But
it might be good to also set a hard upper limit on rowspans.
Regards,
Maciej
Wearing belt AND suspenders never hurts, right? Until there's a
performance hit, I don't see that you can have too many checks.
Any time you put in a hard limit for something, you run the risk of
running into a legitimate case where the hard limit is exceeded. So
it's not just a "belt and suspenders" issue -- there is a real
downside for this kind of change.
A lot of people seem to be interpreting it as a security hole in spite
of the fact that the report says Safari will "crash, and or execute
arbitrary code." I suppose that "and or" maybe gives them an out,
but do
they truly believe that _every_ crashing bug is exploitable?
They aren't thinking at all, is my guess. One person somewhere found
a reproducible crash, and somehow got the idea that it was
potentially a security risk, and he wrote that down somewhere, and
everyone else is just repeating it without thinking.
John
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
