`GetRangeWithMaxLongLength` failing on 32-bit

[Tachi107]

Hi, it seems that commit fceada9ef42ce1af64a1d5941d8009dd0520901a broke the GetRangeWithMaxLongLength test on 32-bit machines - I've tested in a Linux i686 chroot.

Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter = ServerTest.GetRangeWithMaxLongLength
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from ServerTest
[ RUN      ] ServerTest.GetRangeWithMaxLongLength
../test/test.cc:2982: Failure
Expected equality of these values:
  StatusCode::RangeNotSatisfiable_416
    Which is: 416
  res->status
    Which is: 206

../test/test.cc:2983: Failure
Expected equality of these values:
  "0"
  res->get_header_value("Content-Length")
    Which is: "7"

../test/test.cc:2984: Failure
Expected equality of these values:
  false
  res->has_header("Content-Range")
    Which is: true

../test/test.cc:2985: Failure
Expected equality of these values:
  0
  res->body.size()
    Which is: 7

[  FAILED  ] ServerTest.GetRangeWithMaxLongLength (18 ms)
[----------] 1 test from ServerTest (18 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (18 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] ServerTest.GetRangeWithMaxLongLength

 1 FAILED TEST

As shown above, the test response returns a status code of 206 an a Content-Lenght of 7, just like it did before the commit. It's almost like the change was ineffective on 32-bit machines.

I'm pretty sure there's an overflow somewhere in the new code which is only triggered on machines with smaller integer types, but I can't tell where it is.

What do you think is the cause of the problem?

Thanks!