mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Schwartzmeyer <and...@schwartzmeyer.com>
Subject Re: Review Request 54335: Add `os::var()` to Stout.
Date Thu, 08 Dec 2016 19:02:17 GMT


> On Dec. 8, 2016, 6:14 a.m., Alex Clemmer wrote:
> > 3rdparty/stout/include/stout/windows/os.hpp, line 20
> > <https://reviews.apache.org/r/54335/diff/1-2/?file=1575119#file1575119line20>
> >
> >     Tiny nit: while you're messing around with the headers, could we alphabetize
them?

No problem.


- Andrew


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


On Dec. 8, 2016, 1:49 a.m., Andrew Schwartzmeyer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54335/
> -----------------------------------------------------------
> 
> (Updated Dec. 8, 2016, 1:49 a.m.)
> 
> 
> Review request for mesos and Alex Clemmer.
> 
> 
> 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 8443aa0cf0a8d8d52e36282611c2ab15ca4dd354

>   3rdparty/stout/include/stout/windows/os.hpp 2f20ccc64e255a60a1b7f33d684969942f12e45f

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