Bug 85826 - RenderMediaControlsChromium unsigned negation warning
Summary: RenderMediaControlsChromium unsigned negation warning
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Scott Graham
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-07 14:06 PDT by Scott Graham
Modified: 2012-07-19 12:57 PDT (History)
7 users (show)

See Also:


Attachments
Patch (1.77 KB, patch)
2012-05-07 14:10 PDT, Scott Graham
enne: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Graham 2012-05-07 14:06:41 PDT
Building Chromium on Windows reports this warning:

CXX obj\third_party\WebKit\Source\WebCore\rendering\webcore_rendering.RenderMediaControlsChromium.obj
..\..\third_party\WebKit\Source\WebCore\rendering\RenderMediaControlsChromium.cpp(132) : warning C4146: unary minus operator applied to unsigned type, result still unsigned

I think the behaviour is OK as it's passed to an IntRect (and not converted to float), so 2s complement keeps things correct.

It seems a bit safer and less noisy to cast to int, but I'm not sure what the general acceptance of making changes for warnings is.
Comment 1 Scott Graham 2012-05-07 14:10:29 PDT
Created attachment 140587 [details]
Patch
Comment 2 Adrienne Walker 2012-07-18 15:32:15 PDT
Comment on attachment 140587 [details]
Patch

If this warning is still happening, this is an actual bug.  C4146 says that both the operand and the result are non-negative.  For what it's worth, I'm happy to R+ anything that removes warnings on Windows.

Unfortunately, this code doesn't look like it exists any more.  Sad trombone noise.
Comment 3 Scott Graham 2012-07-18 16:12:58 PDT
Thanks.

My (unsubstantiated) interpretation was that X's bit pattern was being negated, but that the value's type was still unsigned.

i.e., 0x00000001 -> 0xFFFFFFFF, not 0x00000001 -> -1 as expected. But then, the 0xFFFFFFFF gets shoved into an int in IntRect which turns it into -1, so it's OK. (Maybe that's wrong though?) If it was passed to a FloatRect it would definitely have been wrong.

Anyway... it's gone now, so it's quiet -> I'm happy. :)