----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56906/#review166996 -----------------------------------------------------------
Patch looks great! Reviews applied: [56906] Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' CONFIGURATION='--verbose' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker-build.sh - Mesos Reviewbot On Feb. 28, 2017, 12:46 a.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/56906/ > ----------------------------------------------------------- > > (Updated Feb. 28, 2017, 12:46 a.m.) > > > Review request for mesos and Anand Mazumdar. > > > Repository: mesos > > > Description > ------- > > The canonical integer type used when dealing with files in Posix > is an `off_t`, or a signed 64-bit integer. In our `FilesProcess`, > we actually use a `size_t`, an unsigned 64-bit integer, to represent > file offsets and lengths. This opens up the potential for passing in > negative values (in 2's complement, an unsigned value greater than > 2^63 - 1 becomes a negative value when casted to a signed value) > for the offset and length. > > In the current code, this leads to a discrepancy in return values > when a caller uses the `/files/read` endpoint versus the `ReadFile` > V1 API: > > Calling `/files/read?offset=9223372036854775808` (2^63) will return a > `400 Bad Request`. Performing the equivalent call via `ReadFile` > will instead return a `200 OK`, with no data actually read. > > > Diffs > ----- > > src/files/files.cpp 8327f8002fbfa3be77a4bbe4aa83a73d0f170f7a > src/tests/api_tests.cpp 24f31ff133185a3224f9edaf8b8532d5630b34c2 > src/tests/files_tests.cpp 6c6353e406249f021803e83909415e9908ded28c > > Diff: https://reviews.apache.org/r/56906/diff/ > > > Testing > ------- > > make check > > src/mesos-tests --gtest_filter="*FilesTest*:*MasterAPITest*" > > > Thanks, > > Joseph Wu > >
