[Webkit-unassigned] [Bug 25645] SVG - numeric overflow for very large elements

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 6 09:17:27 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=25645





--- Comment #23 from Simon Fraser (smfr) <simon.fraser at apple.com>  2010-05-06 09:17:26 PST ---
(In reply to comment #22)

> 1) It appears two of the svg layout tests have errors in their expected
> outputs.
...
> The proposed patch includes corrections for both expected output files.

Sounds good.

> 2) The reason the original patch failed is that, although 2147483647 cannot be
> represented exactly by float, the closest representable value of 2147483648
> will not be obtained when building digit-by-digit using float.
> 
> This proposed patch uses double rather than float for building the
> representation, which is then cast to float. While similar problems could also
> occur with double, fixing that would require a complete overhaul of the number
> parser.

Looks reasonable.

> 3) The original patch also failed on pattern-excessive-malloc.svg, in that its
> render tree dump shows a RenderPath with size 0x0 (not unlike the expected
> output file for mask-excessive-malloc.txt). This occurs due to an incorrect
> conversion from int to float in FloatRect::enclosingIntRect(). The problem
> arises when doing
> 
> float Xf = <value larger than 2147483647>
> int Xi = static_cast<int>(Xf); // now Xi = -2147483648
> 
> When the negative value is returned, later processing detects a rect with
> negative height & width, and changes them to 0.
> 
> A simple, although not entirely elegant, fix is to merely check to see if the
> value is above 2147483647.0f and if it is, return 2147483647 (thus clipping the
> value to the max representable by an int). Similarly for values below
> -2147483647.

Please file a new bug on this issue.

> 4) While hunting down this bug, I noticed at least two other places where
> unsafe float-to-int conversions where taking place. The proposed patch does not
> address these, although they should be fixed. It seems likely that a concerted
> effort would uncover more problematic conversions.
> 
> The constructor IntRect::IntRect(FloatRect &) makes the same float-to-int
> conversion error as does FloatRect::enclosingIntRect().
> 
> In SVGRenderStyle::inflateForShadow(FloatRect &) internal computations are
> performed by (i) converting the FLoatRect to an IntRect, (ii) making the
> required changes, (iii) storing the result back into the FloatRect. This incurs
> the same error as mentioned above.

Please file another new bug on these instances.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list