Fix more MSVC warnings, this time mostly about possible value truncation (fixed

Fix more MSVC warnings, this time mostly about possible value truncation (fixed
by inserting explicit casts; I didn't try to actually change any behavior).

BUG=81439
TEST=none

Committed: https://crrev.com/2b69d595c4800017e738c011b6762b7d5a42c51d
Cr-Commit-Position: refs/heads/master@{#296666}

[Peter Kasting, 2014-09-23 23:50:26]

pkasting@chromium.org changed reviewers:
+ ajwong@chromium.org

[awong, 2014-09-23 23:55:46]

rubber-stamp LGTM

[Peter Kasting, 2014-09-25 06:02:16]

The CQ bit was checked by pkasting@chromium.org

[commit-bot: I haz the power, 2014-09-25 06:03:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/590413006/1

[commit-bot: I haz the power, 2014-09-25 06:33:10]

Committed patchset #1 (id:1) as 7c6cbf5a289bc99ac7fd5b43d497b223bd44aa15

[commit-bot: I haz the power, 2014-09-25 06:33:53]

Patchset 1 (id:??) landed as
https://crrev.com/2b69d595c4800017e738c011b6762b7d5a42c51d
Cr-Commit-Position: refs/heads/master@{#296666}

[scottmg, 2014-09-25 06:44:16]

scottmg@chromium.org changed reviewers:
+ scottmg@chromium.org

[scottmg, 2014-09-25 06:44:16]

https://codereview.chromium.org/590413006/diff/1/base/third_party/dmg_fp/dtoa.cc
File base/third_party/dmg_fp/dtoa.cc (right):

https://codereview.chromium.org/590413006/diff/1/base/third_party/dmg_fp/dtoa...
base/third_party/dmg_fp/dtoa.cc:4147: *s++ = (char)dig + 1;
(man this code is frightening)

this seems like it could potentially be different, should it be (char)(dig + 1)?
or if it's always '0'-'9' just ignore me.

[Peter Kasting, 2014-09-25 08:31:22]

https://codereview.chromium.org/590413006/diff/1/base/third_party/dmg_fp/dtoa.cc
File base/third_party/dmg_fp/dtoa.cc (right):

https://codereview.chromium.org/590413006/diff/1/base/third_party/dmg_fp/dtoa...
base/third_party/dmg_fp/dtoa.cc:4147: *s++ = (char)dig + 1;
On 2014/09/25 06:44:16, scottmg wrote:
> (man this code is frightening)

What's even worse is that we have multiple copies of it in our codebase.

> this seems like it could potentially be different, should it be (char)(dig +
1)?
> or if it's always '0'-'9' just ignore me.

I think it's always 0-9 (otherwise sticking it in the result string is pretty
strange), but let's assume I'm wrong.  What would be a case when the result
would be different?  I can't think of a case where adding one after versus
before casting to char will make a difference, except maybe insofar as signed
overflow is technically undefined, so one form might be undefined and the other
not (but realistically, that's not going to have a practical effect on any of
our compilers).

[scottmg, 2014-09-25 15:45:55]

On 2014/09/25 08:31:22, Peter Kasting wrote:
>
https://codereview.chromium.org/590413006/diff/1/base/third_party/dmg_fp/dtoa.cc
> File base/third_party/dmg_fp/dtoa.cc (right):
> 
>
https://codereview.chromium.org/590413006/diff/1/base/third_party/dmg_fp/dtoa...
> base/third_party/dmg_fp/dtoa.cc:4147: *s++ = (char)dig + 1;
> On 2014/09/25 06:44:16, scottmg wrote:
> > (man this code is frightening)
> 
> What's even worse is that we have multiple copies of it in our codebase.
> 
> > this seems like it could potentially be different, should it be (char)(dig +
> 1)?
> > or if it's always '0'-'9' just ignore me.
> 
> I think it's always 0-9 (otherwise sticking it in the result string is pretty
> strange), but let's assume I'm wrong.  What would be a case when the result
> would be different?  I can't think of a case where adding one after versus
> before casting to char will make a difference, except maybe insofar as signed
> overflow is technically undefined, so one form might be undefined and the
other
> not (but realistically, that's not going to have a practical effect on any of
> our compilers).

Sorry, you're right of course.