----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/52647/#review154530 -----------------------------------------------------------
Fix it, then Ship it! 3rdparty/libprocess/src/decoder.hpp (line 243) <https://reviews.apache.org/r/52647/#comment224130> I wouldn't cast the signed RHS to unsigned here, but instead the unsigned LHS to signed, see more detailed note below. Not originally yours, but one should really use `std::numeric_limits<char>::max()` from `limits` here; alternatively this needs an `#include <limits.h>` 3rdparty/libprocess/src/decoder.hpp (line 438) <https://reviews.apache.org/r/52647/#comment224131> Let's not cast the signed RHS to unsigned here, but instead the unsigned LHS to signed. Not originally yours, but one should really use `std::numeric_limits<char>::max()` from `limits` here; alternatively this needs an `#include <limits.h>` 3rdparty/libprocess/src/encoder.hpp (line 290) <https://reviews.apache.org/r/52647/#comment224133> I think using an `off_t` for a size is semantically incorrect; I'd stay with `size_t`. This requires adjusting the usage above. 3rdparty/libprocess/src/process.cpp (line 3735) <https://reviews.apache.org/r/52647/#comment224134> While `vector<string>::size_type` is the correct type here, we typically just use `size_t`. 3rdparty/libprocess/src/tests/io_tests.cpp (line 284) <https://reviews.apache.org/r/52647/#comment224136> `string::size_type` is the correct type, but we typically just use `size_t`. Not directly an issue, but to me casting the signed LHS to an unsigned type feels more dangerous than casting the unsigned RHS to signed since I feel we seem much less likely deal with very large unsigned values (RHS) than with negative numbers close to zero like `-1` on the RHS. I would personally would cast the RHS instead. What do you think? - Benjamin Bannier On Oct. 27, 2016, 6:51 p.m., Aaron Wood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/52647/ > ----------------------------------------------------------- > > (Updated Oct. 27, 2016, 6:51 p.m.) > > > Review request for mesos, James Peach, Michael Park, and Neil Conway. > > > Bugs: MESOS-6239 > https://issues.apache.org/jira/browse/MESOS-6239 > > > Repository: mesos > > > Description > ------- > > The hardening flags produced many new sign comparison errors in libprocess > that need to be fixed for Mesos to compile/run. > > > Diffs > ----- > > 3rdparty/libprocess/src/decoder.hpp c79296b > 3rdparty/libprocess/src/encoder.hpp 005d1cc > 3rdparty/libprocess/src/process.cpp ab2b5a9 > 3rdparty/libprocess/src/tests/decoder_tests.cpp 4535614 > 3rdparty/libprocess/src/tests/encoder_tests.cpp 9e57375 > 3rdparty/libprocess/src/tests/http_tests.cpp 533104c > 3rdparty/libprocess/src/tests/io_tests.cpp b85c79f > 3rdparty/libprocess/src/tests/subprocess_tests.cpp 0dc1c62 > > Diff: https://reviews.apache.org/r/52647/diff/ > > > Testing > ------- > > Made sure compilation, tests, and benchmarks worked with both gcc and clang. > Ran `make && make check && make bench`. > > > Thanks, > > Aaron Wood > >
