Bug 227896 – PUA characters have the wrong advance in the fast text codepath

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Myles C. Maxfield]

PUA characters have the wrong advance in the fast text codepath

[Myles C. Maxfield]

Created attachment 433389 [details]
Patch

[Myles C. Maxfield]

<rdar://problem/80037103>

[Tim Horton]

Comment on attachment 433389 [details]
Patch

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

> Source/WebCore/platform/graphics/FontCascade.h:254
> +    static bool treatAsSpace(UChar32 c) { return c == ' ' || c == '\t' || c == '\n' || c == noBreakSpace; }

I'm confused why the silent truncation wasn't a compiler error??

> LayoutTests/fast/text/pua-charactersTreatedAsSpace-expected.html:16
> +This test passes if you see a particular pattern of black boxes below.

particular but indescribable?

[EWS]

Committed r279868 (239621@main): <https://commits.webkit.org/239621@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 433389 [details].

[Darin Adler]

Comment on attachment 433389 [details]
Patch

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

>> Source/WebCore/platform/graphics/FontCascade.h:254
>> +    static bool treatAsSpace(UChar32 c) { return c == ' ' || c == '\t' || c == '\n' || c == noBreakSpace; }
> 
> I'm confused why the silent truncation wasn't a compiler error??

Integer truncation has always been silent, with few exceptions. It would be great to find a way to tighten that up.

One trick that can be used in particular cases where we want to be careful to be clever is to overload, making the integer type ambiguous if it’s not a perfect match.