Bug 221194

Summary: Fix longstanding FIXME in parseNumericColor about not doubly clamping color components
Product: WebKit Reporter: Sam Weinig <sam>
Component: New BugsAssignee: Sam Weinig <sam>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, esprehn+autocc, ews-watchlist, glenn, gyuyoung.kim, koivisto, macpherson, menard, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Sam Weinig
Reported 2021-01-31 18:14:03 PST
Fix long standing FIXME in parseNumericColor about not double clamping color components
Attachments
Patch (8.77 KB, patch)
2021-01-31 18:17 PST, Sam Weinig
no flags
Patch (8.82 KB, patch)
2021-02-01 14:15 PST, Sam Weinig
no flags
Patch (8.78 KB, patch)
2021-02-02 09:31 PST, Sam Weinig
no flags
Sam Weinig
Comment 1 2021-01-31 18:17:39 PST
Darin Adler
Comment 2 2021-02-01 12:16:53 PST
Comment on attachment 418838 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=418838&action=review > Source/WebCore/ChangeLog:3 > + Fix long standing FIXME in parseNumericColor about not double clamping color components I realize now that "doubly clamping" is what you mean by "double clamping"; at first I thought it was referring to "double", the C++ type.
Sam Weinig
Comment 3 2021-02-01 13:01:35 PST
(In reply to Darin Adler from comment #2) > Comment on attachment 418838 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=418838&action=review > > > Source/WebCore/ChangeLog:3 > > + Fix long standing FIXME in parseNumericColor about not double clamping color components > > I realize now that "doubly clamping" is what you mean by "double clamping"; > at first I thought it was referring to "double", the C++ type. Heh, yeah, doubly is definitely more clear.
Sam Weinig
Comment 4 2021-02-01 14:15:27 PST Comment hidden (obsolete)
Sam Weinig
Comment 5 2021-02-01 14:18:33 PST Comment hidden (obsolete)
Sam Weinig
Comment 6 2021-02-01 15:40:21 PST Comment hidden (obsolete)
Sam Weinig
Comment 7 2021-02-02 09:31:30 PST Comment hidden (obsolete)
Sam Weinig
Comment 8 2021-02-02 11:09:45 PST
Comment on attachment 419010 [details] Patch Ok, now!
Darin Adler
Comment 9 2021-02-02 11:36:34 PST
Comment on attachment 419010 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419010&action=review > Source/WebCore/css/parser/CSSParserFastPaths.cpp:317 > + ASSERT(localValue <= 255); I see that these functions mostly use 255, not 0xFF, nor some symbolic constant or long horrible thing like static_cast<int>(std::numeric_limits<uint8_t>::max()). For the record, I slightly prefer 0xFF. But there’s no 0xFF.0 for floating point, so maybe that’s a non-starter. > Source/WebCore/css/parser/CSSParserFastPaths.cpp:371 > + uint8_t result = negative ? 0 : tenthAlphaValues[string[length - 2] - '0']; Could stick the character into a local variable instead of the result, if we want to avoid having to state the type of the result.
EWS
Comment 10 2021-02-02 12:14:00 PST
Committed r272226: <https://trac.webkit.org/changeset/272226> All reviewed patches have been landed. Closing bug and clearing flags on attachment 419010 [details].
Radar WebKit Bug Importer
Comment 11 2021-02-02 12:15:22 PST
Note You need to log in before you can comment on or make changes to this bug.