mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Wu <jos...@mesosphere.io>
Subject Re: Review Request 54335: Add `os::var()` to Stout.
Date Thu, 15 Dec 2016 23:48:40 GMT

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


Fix it, then Ship it!




I can fix the spacing before committing.


3rdparty/stout/include/stout/windows/os.hpp (lines 757 - 760)
<https://reviews.apache.org/r/54335/#comment230377>

    Spacing nit: Instead of aligning on the opening parentheses, we prefer to add a newline
and indent with 4 spaces (so 8 spaces total, including the 4 from the `if (`).
    
    Also, period at the end of all comments.


- Joseph Wu


On Dec. 15, 2016, 3:44 p.m., Andrew Schwartzmeyer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54335/
> -----------------------------------------------------------
> 
> (Updated Dec. 15, 2016, 3:44 p.m.)
> 
> 
> Review request for mesos, Alex Clemmer and Joseph Wu.
> 
> 
> Bugs: MESOS-6677 and MESOS-6722
>     https://issues.apache.org/jira/browse/MESOS-6677
>     https://issues.apache.org/jira/browse/MESOS-6722
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Returns `/var` on POSIX and (usually) `C:\ProgramData` on Windows. Uses
> Windows COM API to look up correct location for persistent,
> app-local (but not per user) variable data. Returns standard location on
> POSIX.
> 
> The addition of `os::var()` is a continuation of the fix in #54336. The
> correct place for variable runtime data on Windows is not necessarily in
> `os::temp()`, but in the analogous location `ProgramData`. Thus we need
> a platform-agnostic way to refer to `var`.
> 
> The call to `ShGetKnownFolder` is not RAII because it is a C API, and
> the ATL `CComHeapPtr` class is not used in this commit due to Windows
> header issues. Thus the buffer allocated by the C API is freed
> immediately after the data is copied into a `std::wstring`. Because the
> Windows API returns a UTF-16 string, and Unicode characters are valid in
> Windows path names, we have to correctly convert it to UTF-8 using
> `<codecvt>`.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/stout/posix/os.hpp 05d27a0beacfdd706b0c5c2e5d28465ca3e118fb

>   3rdparty/stout/include/stout/windows.hpp d89c70902cf60544441608c2cb290b0727cbb45c 
>   3rdparty/stout/include/stout/windows/os.hpp 51c8dcfab135d0323369e4605c67cf6df4a9671e

> 
> Diff: https://reviews.apache.org/r/54335/diff/
> 
> 
> Testing
> -------
> 
> make && make check on Linux: no failures.
> msbuild and attach to a master on Windows: no failures.
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>


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