> On Nov. 2, 2016, 11:52 a.m., Benjamin Bannier wrote: > > 3rdparty/libprocess/src/encoder.hpp, line 290 > > <https://reviews.apache.org/r/52647/diff/4/?file=1547640#file1547640line290> > > > > I think using an `off_t` for a size is semantically incorrect; I'd stay > > with `size_t`. This requires adjusting the usage above. > > Aaron Wood wrote: > James Peach and I had a discussion about this and thought that `off_t` is > more correct for representing file sizes. Why would you prefer to stick with > `size_t`? > > James Peach wrote: > `FileEncoder` is taking the size of a file, which is `off_t`. The only > use of this class is `FileEncoder(socket, fd, s.st_size)`, which is > implicitly converting the `off_t` to `size_t`. If I had realized that at the > time, I would have asked for the `FileEncoder` constructor to also take an > `off_t` :)
I understand, dropping. > On Nov. 2, 2016, 11:52 a.m., Benjamin Bannier wrote: > > 3rdparty/libprocess/src/process.cpp, line 3735 > > <https://reviews.apache.org/r/52647/diff/4/?file=1547641#file1547641line3735> > > > > While `vector<string>::size_type` is the correct type here, we > > typically just use `size_t`. > > Aaron Wood wrote: > Wouldn't `container::size_type` be more portable? `size_t` could vary on > the platform where `size_type` is container dependent. No, I believe `size_t` is safe here. If I am reading the standard correctly, `container::size_type` represents "a type that can represent the size of the largest object in the allocation model" (`size_type` comes out of the allocator used for the container), and the possible range for `size_t` might be even bigger, but never smaller ("The type `size_t` is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object"). This means that using `size_t` as iteration variable when iterating over a container should never cause truncation. Also note that for `std::allocator` (which we use for our containers) `size_type` is a `typedef` for `size_t`, and in C++17 `allocator::size_type` is deprecated altogether. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/52647/#review154530 ----------------------------------------------------------- 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 > >
