[chromium] Use floating point literals in expressions that initialize floats
Created attachment 161144 [details] Patch
Comment on attachment 161144 [details] Patch This is technically against WebKit style, but given that this code is going to GTFO, this seems fine.
Comment on attachment 161144 [details] Patch Attachment 161144 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13690106 New failing tests: CCLayerTreeHostTestAtomicCommitWithPartialUpdate.runMultiThread
Comment on attachment 161144 [details] Patch Clearing flags on attachment: 161144 Committed r126981: <http://trac.webkit.org/changeset/126981>
All reviewed patches have been landed. Closing bug.
For those of us not building with VS, should we always be using f suffix? It surprises me that these are the only double literal->float truncations in our code base, are these somehow special?
> For those of us not building with VS, should we always be using f suffix? Nope. > It surprises me that these are the only double literal->float truncations in our code base, are these somehow special? They're special because we're in the process of moving this code out of WebKit to a location where more warnings are enabled.
(In reply to comment #7) > > For those of us not building with VS, should we always be using f suffix? > > Nope. > > > It surprises me that these are the only double literal->float truncations in our code base, are these somehow special? > > They're special because we're in the process of moving this code out of WebKit to a location where more warnings are enabled. Right, I am wondering about future compositor code, not WebKit :) For example we have tons of things like FloatPoint(0.5, 0) in our tests. These are using a double literal for a float as well, but are not causing compiler warnings?
The WebKit style is "use f if you need to force floating-point math". In this instances, we need to force floating point math or MSVS warns (somewhat correctly) that the narrowing conversion is lossly. Initializing to 0.5, 0 probably doesn't need anything since 0.5 and 0 are exactly representable as doubles and floats, so it's not lossy. I'm guessing that since 0.1, 0.01, and 0.95 do not have exact representations as doubles or floats, and the float representation is not equivalent to the double representation, the compiler is less happy.