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