WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
239389
RenderDeprecatedFlexibleBox::applyLineClamp should use size_t
https://bugs.webkit.org/show_bug.cgi?id=239389
Summary
RenderDeprecatedFlexibleBox::applyLineClamp should use size_t
zalan
Reported
2022-04-15 08:55:20 PDT
see
bug 239029
Attachments
Patch
(5.73 KB, patch)
2022-04-15 09:18 PDT
,
zalan
no flags
Details
Formatted Diff
Diff
Patch
(5.82 KB, patch)
2022-04-16 15:43 PDT
,
zalan
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
zalan
Comment 1
2022-04-15 09:18:44 PDT
Created
attachment 457704
[details]
Patch
Darin Adler
Comment 2
2022-04-15 14:04:23 PDT
Comment on
attachment 457704
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=457704&action=review
> Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:988 > +static std::optional<LayoutUnit> getHeightForLineCount(const RenderBlockFlow& block, size_t lineCount, bool includeBottom, size_t& count)
If we are changing the return type, it would be better to return a structure with both the count and the height, instead of using a return value plus an out argument. But maybe count is an in/out argument?
> Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:1003 > + return *height + obj->y() + (includeBottom ? (block.borderBottom() + block.paddingBottom()) : 0_lu);
I am not familiar with how we avoid overflow in math like this; do we stay far from the limits of the LayoutUnit type to avoid it? Is there a guarantee that this expression won’t overflow?
> Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:1066 > + size_t numVisibleLines = lineClamp.isPercentage() ? std::max<size_t>(1, (maxLineCount + 1) * lineClamp.value() / 100) : lineClamp.value();
What prevents overflow in the expression "(maxLineCount + 1) * lineClamp.value() / 100"?
zalan
Comment 3
2022-04-16 12:21:21 PDT
(In reply to Darin Adler from
comment #2
)
> Comment on
attachment 457704
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=457704&action=review
> > > Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:988 > > +static std::optional<LayoutUnit> getHeightForLineCount(const RenderBlockFlow& block, size_t lineCount, bool includeBottom, size_t& count) > > If we are changing the return type, it would be better to return a structure > with both the count and the height, instead of using a return value plus an > out argument. > > But maybe count is an in/out argument?
I agree, I don't particularly like this setup. 'count' is an in/out argument.
> > Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:1003 > > + return *height + obj->y() + (includeBottom ? (block.borderBottom() + block.paddingBottom()) : 0_lu); > > I am not familiar with how we avoid overflow in math like this; do we stay > far from the limits of the LayoutUnit type to avoid it? Is there a guarantee > that this expression won’t overflow?
The last time I looked LayoutUnit used saturated arithmetic.
> > > Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:1066 > > + size_t numVisibleLines = lineClamp.isPercentage() ? std::max<size_t>(1, (maxLineCount + 1) * lineClamp.value() / 100) : lineClamp.value(); > > What prevents overflow in the expression "(maxLineCount + 1) * > lineClamp.value() / 100"?
Yeah, nothing really. In practice I don't think we could produce this high amount of lines, but it should not stop us from trying to avoid arithmetic overflow.
zalan
Comment 4
2022-04-16 15:43:01 PDT
Created
attachment 457756
[details]
Patch
EWS
Comment 5
2022-04-17 06:33:49 PDT
Committed
r292948
(
249713@main
): <
https://commits.webkit.org/249713@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 457756
[details]
.
Radar WebKit Bug Importer
Comment 6
2022-04-17 06:34:14 PDT
<
rdar://problem/91861450
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug