----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66437/#review200500 -----------------------------------------------------------
3rdparty/stout/include/stout/os/windows/close.hpp Lines 38 (patched) <https://reviews.apache.org/r/66437/#comment281244> Note that this will cause an SEH exception for `FsTest.Close` when run under a debugger, because it purposefully closes a handle twice. Not sure what we can do about that other than delete that part of the test. 3rdparty/stout/include/stout/os/windows/fd.hpp Line 52 (original), 54 (patched) <https://reviews.apache.org/r/66437/#comment281245> This part of the `enum` I don't think is necessary. It made sense for default construction, but we can probably get away without it. 3rdparty/stout/include/stout/os/windows/fd.hpp Lines 120-132 (patched) <https://reviews.apache.org/r/66437/#comment281246> I am not a fan of this, as it can cause ambigous types to crop up. Working on writing comparison operators that will work without this `operator. int()` - Andrew Schwartzmeyer On April 3, 2018, 10:55 p.m., Andrew Schwartzmeyer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66437/ > ----------------------------------------------------------- > > (Updated April 3, 2018, 10:55 p.m.) > > > Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, > and Michael Park. > > > Bugs: MESOS-8675 and MESOS-8683 > https://issues.apache.org/jira/browse/MESOS-8675 > https://issues.apache.org/jira/browse/MESOS-8683 > > > Repository: mesos > > > Description > ------- > > After all the CRT APIs were replaced with Windows APIs, we no longer > need to support the semantics of an `int` file descriptor in > general (in the sense of opening a CRT handle that's associated with > the actual kernel object for the given `HANDLE`). There are specific > use cases (usually third-party code) which still require a CRT > int-like file descriptor, which the `crt()` function explicitly > allocates (this allocation used to be done in the constructor). > > Thus the entire `FD_CRT` type was removed from the `WindowsFD` > abstraction. It still acts like an `int` in the sense that it can be > constructed from one and compared to one. However, construction via > `int` only supports the standard file descriptors 0, 1, and 2 for > `stdin`, `stdout`, and `stderr`. Any other construction creates an > `int_fd` which holds an `INVALID_HANDLE` value. When being compared to > an `int`, the abstraction simply returns -1 if it is invalid (based on > the result of the `is_valid()` method) or 0 if it is valid. This is to > support the semantics of checking validity by something like > `if (fd < 0)` or `if (fd == -1)`. > > With the deletion of the `FD_CRT` type from `WindowsFD`, all the Stout > APIs that switched on the type were simplified, with the last of the > CRT code deleted. > > Note that a new enum type `INVALID` was added to support default > construction semantics, and only exists for that reason. An actual > "invalid" handle should be constructed via `int_fd fd = -1` (or > `int_fd fd = INVALID_HANDLE_VALUE` when being explicit on Windows). > > Because `int_fd` is now castable to an `int`, and the `FD_CRT` type > was removed, the comparison operators became much simpler. > > > Diffs > ----- > > 3rdparty/stout/include/stout/os/windows/close.hpp > ff635e44235d63888a210cd68d49f6678a851e31 > 3rdparty/stout/include/stout/os/windows/dup.hpp > 265046cf7ffc14f7326711d295aa7dd4f0a8a1e3 > 3rdparty/stout/include/stout/os/windows/fcntl.hpp > bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa > 3rdparty/stout/include/stout/os/windows/fd.hpp > d7f8cdf1ad877eb55589bf5a9e75d295f91990a7 > 3rdparty/stout/include/stout/os/windows/read.hpp > 8047ad590fcc46d3ec46b551472d8c518ae49cc1 > 3rdparty/stout/include/stout/os/windows/write.hpp > 71006489918d9495d37d2fdfdca08b40b419481a > 3rdparty/stout/tests/os/filesystem_tests.cpp > c190baa2230298e428d4034b90dccffb59b4e710 > > > Diff: https://reviews.apache.org/r/66437/diff/1/ > > > Testing > ------- > > > Thanks, > > Andrew Schwartzmeyer > >
