Fix GCC 4.7 warnings, which are related to char being signed in GCC

Fix GCC 4.7 warnings, which are related to char being signed in GCC
("narrowing conversion ... inside { } is ill-formed in C++11").

* src/mksnapshot.cc: Cast "char" to "unsigned char" when outputting snapshot. 
* test/cctest/test-regexp.cc: Use static_cast to uc16 as the char
literal is signed.

Committed: http://code.google.com/p/v8/source/detail?r=10241

[Tobias Burnus, 2011-12-06 20:32:49]

Part two of the effort to make v8 buildable with GCC "4.7.0 (experimental)",
which also included filling two PR (problem reports) at gcc.gnu.org about
internal compiler errors (one is already fixed).

"A narrowing conversion is an implicit conversion [...] from an integer type or
unscoped enumeration type to an integer type that cannot represent all the
values of the original type, except where the source is a constant expression
and the actual value after conversion will fit into the target type and will
produce the original value when converted back to the original type."

That was violated for the generated geni/snapshot.cc: The values were negative
(generated from signed char) but the data type was "byte" which has been
typedefed as unsigned.

[Vyacheslav Egorov (Chromium), 2011-12-12 18:06:17]

http://codereview.chromium.org/8825003/diff/3001/src/mksnapshot.cc
File src/mksnapshot.cc (right):

http://codereview.chromium.org/8825003/diff/3001/src/mksnapshot.cc#newcode112
src/mksnapshot.cc:112: fprintf(fp, "%d", at(j));
Instead of using unsigned char you can probably just add a cast from char to
unsigned char here. This will be a smaller yet more correct change (as it
conveys our intent directly --- we want all printed values to be positive).

What do you think?

http://codereview.chromium.org/8825003/diff/3001/src/mksnapshot.cc#newcode237
src/mksnapshot.cc:237: output_ = new i::ScopedVector<unsigned
char>((input.length() * 101) / 100
Usually we are leaving operation on the previous line.

You can break the line after >( if + does not fit.

http://codereview.chromium.org/8825003/diff/3001/test/cctest/test-regexp.cc
File test/cctest/test-regexp.cc (right):

http://codereview.chromium.org/8825003/diff/3001/test/cctest/test-regexp.cc#n...
test/cctest/test-regexp.cc:840: const_cast<uc16>('\xa0')};
Why do you need const_cast here? const_cast is for changing constness not type.

http://codereview.chromium.org/8825003/diff/3001/test/cctest/test-regexp.cc#n...
test/cctest/test-regexp.cc:861: const_cast<uc16>('\xa0')};
Ditto.

[Tobias Burnus, 2011-12-12 21:54:00]

Review fixes:
- Only a cast for printf
- Use static_cast instead of const_cast
- Add entry to AUTHORS

http://codereview.chromium.org/8825003/diff/3001/src/mksnapshot.cc
File src/mksnapshot.cc (right):

http://codereview.chromium.org/8825003/diff/3001/src/mksnapshot.cc#newcode112
src/mksnapshot.cc:112: fprintf(fp, "%d", at(j));
On 2011/12/12 18:06:17, Vyacheslav Egorov wrote:
> you can probably just add a cast from char to
> unsigned char here. This will be a smaller yet more
> correct change (as it conveys our intent directly

I agree that the patch will be shorter. I am not sure that it is more correct.
With the current patch, no cast is needed which I regard as more correct than
adding a cast. However, I am open for either solution.

http://codereview.chromium.org/8825003/diff/3001/test/cctest/test-regexp.cc
File test/cctest/test-regexp.cc (right):

http://codereview.chromium.org/8825003/diff/3001/test/cctest/test-regexp.cc#n...
test/cctest/test-regexp.cc:840: const_cast<uc16>('\xa0')};
On 2011/12/12 18:06:17, Vyacheslav Egorov wrote:
> Why do you need const_cast here? const_cast is for
> changing constness not type.

True, a static_cast should be sufficient. (In the patch description I actually
claimed that I were using a static_cast.)

[Vyacheslav Egorov (Chromium), 2011-12-13 12:43:20]

LGTM

I will be landing.