> On June 23, 2015, 5:29 p.m., Vinod Kone wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp, line 76
> > <https://reviews.apache.org/r/34256/diff/7/?file=990278#file990278line76>
> >
> >     don't you want to do the same short circuit as in basename() for path 
> > containing only slashes?

In `basename` that short-circuit is needed. For `basename` consider `"///"` as 
input, the expected (= `::basename`) output would be `"/"` but without that 
clause the resulting output would be `""`. In `dirname` however that is not 
needed. Same example as before, `"///"` is expected to return `"/"` and that is 
exactly what we get. Feel free to reopen this issue in case I missed something.


- Till


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


On June 24, 2015, 2:44 a.m., Till Toenshoff wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/34256/
> -----------------------------------------------------------
> 
> (Updated June 24, 2015, 2:44 a.m.)
> 
> 
> Review request for mesos and Cody Maloney.
> 
> 
> Bugs: MESOS-1303
>     https://issues.apache.org/jira/browse/MESOS-1303
> 
> 
> Repository: mesos-incubating
> 
> 
> Description
> -------
> 
> Introducing Path::dirname() and Path::basename() as a thread safe replacement 
> of the respective system functions. Also contains new tests covering corner 
> cases.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp 
> 59595c9d0372cb7fc8ec5acbab91ee298b673167 
>   3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp 
> 7dd266421377e3f531c15cdf17377141f26c2715 
> 
> Diff: https://reviews.apache.org/r/34256/diff/
> 
> 
> Testing
> -------
> 
> make check (including new tests).
> 
> Result comparison to match ::dirname and ::basename on interesting cases.
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>

Reply via email to