> 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 > >
