> On Jan. 14, 2016, midnight, Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/internal/windows/reparsepoint.hpp,
> >  lines 95-96
> > <https://reviews.apache.org/r/39803/diff/8/?file=1192868#file1192868line95>
> >
> >     I don't quite understand why these are `std::wstring`. It seems like we 
> > do some `x / sizeof(WCHAR)` to make this work? Could you elaborate on this 
> > a little bit please?
> 
> Alex Clemmer wrote:
>     It sounds like there might be two questions here: (1) why are we dividing 
> by `sizeof(WCHAR)` to calculate the index of the beginning/ending offsets, 
> and (2) why does the `SymbolicLink` data structure use `wchar`. Let me 
> address both of them.
>     
>     First, the division by `sizeof(WCHAR)` is because the offsets in the 
> `REPARSE_DATA_BUFFER` are actually _byte_ offsets, not array index offsets. 
> Thus, to calculate the actual array index of the beginning and ending of the 
> `printName` and `substituteName`, we need to divide by `sizeof(WCHAR)`. This 
> converts the byte offset into an array index offset.
>     
>     Second, the `SymbolicLink` data structure uses `wstring` because (1) the 
> goal is for `SymbolicLink` to be a convenient, internal-only way to interact 
> with the data in a `REPARSE_DATA_BUFFER`, and (2) converting to `string` is 
> really hard and not necessary for this goal.
>     
>     I think part of the confusion is that it seemed like the division by 
> `sizeof(WCHAR)` might mean that these fields aren't really `wstring`, which 
> is not the case.
>     
>     Does this clarify things?

Yep. As far as I understand, the crux of the funky comes from the fact that 
`REPARSE_DATA_BUFFER` stores wide chars but specifies byte offsets.


- Michael


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


On Jan. 15, 2016, 1:58 a.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39803/
> -----------------------------------------------------------
> 
> (Updated Jan. 15, 2016, 1:58 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Michael Hopcroft, Joris Van 
> Remoortere, and Joseph Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Windows: Implemented stout/os/stat.hpp`.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/Makefile.am 
> ec851dcb08d938defeb6066810011e003d594b29 
>   
> 3rdparty/libprocess/3rdparty/stout/include/stout/internal/windows/reparsepoint.hpp
>  PRE-CREATION 
>   
> 3rdparty/libprocess/3rdparty/stout/include/stout/internal/windows/symlink.hpp 
> PRE-CREATION 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/stat.hpp 
> ffe074830ef90f492990bf695e686c885b9a155c 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/windows/stat.hpp 
> 5b38b9af654d7d1c574f0cc573083b66693ced1d 
>   3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp 
> 27edf1b4f8647a2720f2962eafa110d694b3baed 
> 
> Diff: https://reviews.apache.org/r/39803/diff/
> 
> 
> Testing
> -------
> 
> `make check` from autotools on Ubuntu 15.
> `make check` from CMake on OS X 10.10.
> Ran `check` project in VS on Windows 10.
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Reply via email to