mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Park" <mp...@apache.org>
Subject Re: Review Request 39803: Windows: Implemented stout/os/stat.hpp`.
Date Fri, 15 Jan 2016 02:48:09 GMT


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message