Bug 67976

Summary: Remove remnants of code that assume Lengths are 28 bit integers.
Product: WebKit Reporter: Luke Macpherson <macpherson>
Component: New BugsAssignee: Luke Macpherson <macpherson>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, dglazkov, eae, eric, leviw, macpherson, menard, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 81509    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Description Luke Macpherson 2011-09-12 17:57:23 PDT
Remove remnants of code that assume Lengths are 28 bit integers.
Comment 1 Luke Macpherson 2011-09-12 18:10:55 PDT
Created attachment 107119 [details]
Patch
Comment 2 WebKit Review Bot 2011-09-12 21:30:09 PDT
Comment on attachment 107119 [details]
Patch

Attachment 107119 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/9651043

New failing tests:
fast/table/max-width-integer-overflow.html
Comment 3 Eric Seidel (no email) 2011-09-13 01:48:02 PDT
Comment on attachment 107119 [details]
Patch

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

> Source/WebCore/rendering/AutoTableLayout.cpp:271
> +        maxWidth = std::numeric_limits<LayoutUnit>::max();

Why is this LayoutUnit::max and the other is INT_MAX?  Does Length use LayoutUnit or int?
Comment 4 Luke Macpherson 2011-09-13 15:48:21 PDT
Comment on attachment 107119 [details]
Patch

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

> Source/WebCore/css/CSSPrimitiveValue.cpp:333
> +    return Length(roundForImpreciseConversion<int, INT_MAX, INT_MIN>(computeLengthDouble(style, rootStyle, multiplier, computingFontSize)), Fixed);

I used INT_MAX here in order to be consistent with the existing code there that uses INT_MAX/SHRT_MAX/USHRT_MAX etc. for rounding. I'll make the computeLengthDouble macro take a single template parameter in a follow up change.

>> Source/WebCore/rendering/AutoTableLayout.cpp:271
>> +        maxWidth = std::numeric_limits<LayoutUnit>::max();
> 
> Why is this LayoutUnit::max and the other is INT_MAX?  Does Length use LayoutUnit or int?

Context: LayoutUnit is an intermediate typedef that is currently an int, and is intended to be switched to a float at some point in the future once eae is done refactoring to use floats everywhere.
As far as I can tell, using the 28 bit max here was incorrect, as mawWidth is a LayoutUnit, not a Length anyway, so it was using an irrelevant constant from a different type...
Now, to your questions:
1) I used numeric_limits<LayoutUnit>::max() here because the underlying type or LayoutUnit is intended to change in the future.
2) Length does not use LayoutUnit, but maxWidth is not a Length, it is a LayoutUnit.
Comment 5 Luke Macpherson 2011-09-13 15:51:12 PDT
Comment on attachment 107119 [details]
Patch

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

>> Source/WebCore/css/CSSPrimitiveValue.cpp:333
>> +    return Length(roundForImpreciseConversion<int, INT_MAX, INT_MIN>(computeLengthDouble(style, rootStyle, multiplier, computingFontSize)), Fixed);
> 
> I used INT_MAX here in order to be consistent with the existing code there that uses INT_MAX/SHRT_MAX/USHRT_MAX etc. for rounding. I'll make the computeLengthDouble macro take a single template parameter in a follow up change.

That should have been roundForImpreciseConversion, and it's not a macro, it's a function. I think I need caffeine.
Comment 6 Luke Macpherson 2011-09-19 21:48:50 PDT
Created attachment 107966 [details]
Patch
Comment 7 WebKit Review Bot 2011-09-20 05:06:18 PDT
Comment on attachment 107966 [details]
Patch

Attachment 107966 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/9765237

New failing tests:
fast/table/max-width-integer-overflow.html
Comment 8 Eric Seidel (no email) 2012-02-28 23:41:51 PST
Comment on attachment 107966 [details]
Patch

Looks like this breaks a test?
Comment 9 Luke Macpherson 2012-03-18 19:59:48 PDT
Created attachment 132527 [details]
Patch
Comment 10 WebKit Review Bot 2012-03-18 20:54:38 PDT
Comment on attachment 132527 [details]
Patch

Attachment 132527 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11976892

New failing tests:
fast/table/max-width-integer-overflow.html
Comment 11 Luke Macpherson 2012-03-18 21:33:04 PDT
Created attachment 132540 [details]
Patch
Comment 12 Eric Seidel (no email) 2012-03-18 23:06:06 PDT
Comment on attachment 132540 [details]
Patch

OK.
Comment 13 WebKit Review Bot 2012-03-18 23:38:10 PDT
Comment on attachment 132540 [details]
Patch

Clearing flags on attachment: 132540

Committed r111156: <http://trac.webkit.org/changeset/111156>
Comment 14 WebKit Review Bot 2012-03-18 23:38:15 PDT
All reviewed patches have been landed.  Closing bug.