[webkit-reviews] review granted: [Bug 215051] Unconditionally record string offsets in the fast text codepath : [Attachment 405776] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Aug 1 21:03:09 PDT 2020


Darin Adler <darin at apple.com> has granted Myles C. Maxfield
<mmaxfield at apple.com>'s request for review:
Bug 215051: Unconditionally record string offsets in the fast text codepath
https://bugs.webkit.org/show_bug.cgi?id=215051

Attachment 405776: Patch

https://bugs.webkit.org/attachment.cgi?id=405776&action=review




--- Comment #4 from Darin Adler <darin at apple.com> ---
Comment on attachment 405776
  --> https://bugs.webkit.org/attachment.cgi?id=405776
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=405776&action=review

> Source/WebCore/platform/graphics/FontCascade.cpp:1266
> -	   ASSERT_WITH_SECURITY_IMPLICATION(offsetInString < textRun.length());
> +	   RELEASE_ASSERT_WITH_SECURITY_IMPLICATION(offsetInString <
static_cast<GlyphBufferStringOffset>(textRun.length()));

Changing this to a RELEASE_ASSERT makes it unnecessary to have it inside an if
statement that checks the same thing. Just put this outside the if and don’t
check this in the if.

> Source/WebCore/platform/graphics/FontCascade.cpp:1273
> +	   U16_NEXT(textRun.characters16(), offsetInString,
static_cast<GlyphBufferStringOffset>(textRun.length()), baseCharacter);

Can we put static_cast<GlyphBufferStringOffset>(textRun.length()) in a local
variable? The long expression makes it hard to see what is going on. And we
could probably convert without a cast if we used a local. And we use it twice,
once here and once in the assertion.

Also, seems like this should be U16_GET, not U16_NEXT. We don’t want to bump
offsetInString. And if we did, we’d have to do it in the 8-bit case above.


More information about the webkit-reviews mailing list