> On Oct. 18, 2016, 3:14 a.m., James Peach wrote:
> > 3rdparty/libprocess/src/tests/io_tests.cpp, line 284
> > <https://reviews.apache.org/r/52647/diff/3/?file=1538065#file1538065line284>
> >
> >     Can you just make ``length`` type ``ssize_t``?
> 
> Aaron Wood wrote:
>     `length` is `ssize_t` (set on line 235)

Ok I see. It is bogus that ``length`` is ``ssize_t`` since ``io::read`` is 
returning ``Future<size_t>``. Just make ``length`` a ``size_t``.


> On Oct. 18, 2016, 3:14 a.m., James Peach wrote:
> > 3rdparty/libprocess/src/encoder.hpp, line 291
> > <https://reviews.apache.org/r/52647/diff/3/?file=1538060#file1538060line291>
> >
> >     It's not obvious to me that this is the right change since the 
> > surrounding code tries to deal with ``off_t``. Can you explain this some 
> > more?
> 
> Aaron Wood wrote:
>     In the `backup` method on line 276 it's being compared with a `size_t` as 
> well as in the `remaining` method on line 283. But in `next` on line 267 
> `size` which is a `size_t` is being casted to an `off_t` and then assigned to 
> `index`. 
>     
>     The other encoders above in that file seem to be working with their own 
> private `index` as a `size_t` so even though it looks like it's being used in 
> different ways in `FileEncoder` I thought it should be a `size_t`.
>     
>     Since this specific class is for files maybe we should keep it as `off_t` 
> and just cast the things used for comparisons to `off_t`.

``off_t`` is the "more correct" type for representing file sizes, but 
``FileEncoder`` seems a bit schizophrenic. I'd be inclined to keep both 
``size`` and ``index`` as ``off_t``, then cast ``length`` as appropriate.


- James


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52647/#review153024
-----------------------------------------------------------


On Oct. 21, 2016, 6:29 p.m., Aaron Wood wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52647/
> -----------------------------------------------------------
> 
> (Updated Oct. 21, 2016, 6:29 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 18a8e20 
>   3rdparty/libprocess/src/tests/decoder_tests.cpp 4535614 
>   3rdparty/libprocess/src/tests/encoder_tests.cpp 9e57375 
>   3rdparty/libprocess/src/tests/http_tests.cpp 8d6c8c4 
>   3rdparty/libprocess/src/tests/io_tests.cpp b85c79f 
>   3rdparty/libprocess/src/tests/subprocess_tests.cpp c8350cf 
> 
> 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
> 
>

Reply via email to