Fixes for re-enabling more MSVC level 4 warnings: base/ edition

Fixes for re-enabling more MSVC level 4 warnings: base/ edition

This contains fixes for the following sorts of issues:
* Signedness mismatch
* Assignment inside conditional
* Nonstandard extension: unnamed struct/union
* Octal escape sequence terminated by decimal number
* Possibly-uninitialized local variable

This also contains a very small number of other cleanups/simplifications to
nearby code.

BUG=81439
TEST=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=281204

[Peter Kasting, 2014-07-03 00:24:25]

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h
File base/basictypes.h (right):

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h#newcode49
base/basictypes.h:49: const  int8  kint8min   = -0x7F - 1;
This is the trick that limits.h uses for these (on MSVC, at least).

[awong, 2014-07-03 00:54:01]

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h
File base/basictypes.h (right):

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h#newcode49
base/basictypes.h:49: const  int8  kint8min   = -0x7F - 1;
On 2014/07/03 00:24:24, Peter Kasting wrote:
> This is the trick that limits.h uses for these (on MSVC, at least).

This concerns me. We are underflowing a signed int which, IIRC, is undefined
behavior.

What's wrong with 0x80 here?

[Peter Kasting, 2014-07-03 00:59:52]

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h
File base/basictypes.h (right):

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h#newcode49
base/basictypes.h:49: const  int8  kint8min   = -0x7F - 1;
On 2014/07/03 00:54:01, awong wrote:
> On 2014/07/03 00:24:24, Peter Kasting wrote:
> > This is the trick that limits.h uses for these (on MSVC, at least).
> 
> This concerns me. We are underflowing a signed int which, IIRC, is undefined
> behavior.

I don't see how we're underflowing things.  -0x7F = -127, which isn't on the
border of what a signed int can represent.  It isn't even on the border of what
a (signed) int8 can represent, which would be -128.

> What's wrong with 0x80 here?

0x80 is a larger positive value than an int8 can represent (128 vs. 127).

[awong, 2014-07-03 01:07:45]

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h
File base/basictypes.h (right):

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h#newcode49
base/basictypes.h:49: const  int8  kint8min   = -0x7F - 1;
On 2014/07/03 00:59:52, Peter Kasting wrote:
> On 2014/07/03 00:54:01, awong wrote:
> > On 2014/07/03 00:24:24, Peter Kasting wrote:
> > > This is the trick that limits.h uses for these (on MSVC, at least).
> > 
> > This concerns me. We are underflowing a signed int which, IIRC, is undefined
> > behavior.
> 
> I don't see how we're underflowing things.  -0x7F = -127, which isn't on the
> border of what a signed int can represent.  It isn't even on the border of
what
> a (signed) int8 can represent, which would be -128.

Bah. You're right. I've very bad at hex. :(

> 
> > What's wrong with 0x80 here?
> 
> 0x80 is a larger positive value than an int8 can represent (128 vs. 127).
Okay...dumb question...why -0x7F - 1 instead of -0x80?

[Peter Kasting, 2014-07-03 01:11:54]

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h
File base/basictypes.h (right):

https://codereview.chromium.org/368133002/diff/30001/base/basictypes.h#newcode49
base/basictypes.h:49: const  int8  kint8min   = -0x7F - 1;
On 2014/07/03 01:07:45, awong wrote:
> Okay...dumb question...why -0x7F - 1 instead of -0x80?

MSVC also errors on that; it's what I tried first.  I forget the exact error,
but IIRC the issue is that the compiler tries to do the equivalent of:

int8 x = -static_cast<int8>(0x80);

...which trips the "0x80 can't be represented by this type" error again.

There are probably C++ conversion/promotion rules that describe this exactly,
but I always have to look that stuff up when I need to know it.

(My secret hope is that the big DEPRECATED on this section means we can just
ditch all these and convert callers to using the values in the standard headers,
but that's beyond the scope of this change :( )

[awong, 2014-07-03 01:13:10]

LGTM

What could possibly go wrong.™

[Peter Kasting, 2014-07-03 01:19:33]

The CQ bit was checked by pkasting@chromium.org

[commit-bot: I haz the power, 2014-07-03 01:21:48]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/pkasting@chromium.org/368133002/50001

[commit-bot: I haz the power, 2014-07-03 07:03:51]

Change committed as 281204