----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54591/#review164273 -----------------------------------------------------------
3rdparty/stout/include/stout/os/windows/fd.hpp (line 20) <https://reviews.apache.org/r/54591/#comment235939> Should these be alphabetized? 3rdparty/stout/include/stout/os/windows/fd.hpp (line 59) <https://reviews.apache.org/r/54591/#comment235941> I'm not super up on the semantics of these newfangled C++11 constructor things, but is there any particular reason we need this to be trivially constructible, or anything like that? Because, if there's not any significant gain, I think it's worth wondering whether having a default value is slightly dangerous. 3rdparty/stout/include/stout/os/windows/fd.hpp (line 71) <https://reviews.apache.org/r/54591/#comment235940> Is it true that we're expecting `HANDLE`s passed to this class to only correspond to files? If not, I think it's worth noting that `INVALID_HANDLE_VALUE` is not the error value of all `HANDLE`s returned from the win32 APIs, _cf_. the "documentation" at [1]. Depending on the "type" of `HANDLE` returned, an error could be denoted by the handle being `== NULL`, `== -1`, and even `<= 32` in the case of `ShellExecute`. See [2]. If yes, I think it's worth at least documenting this as part of the class. (Honestly, I would prefer file `HANDLE`s be a different type entirely, but here we are.) [1] https://blogs.msdn.microsoft.com/oldnewthing/20040302-00/?p=40443 [2] http://stackoverflow.com/questions/3905538/testing-for-an-invalid-windows-handle-should-i-compare-with-null-0-or-even 3rdparty/stout/include/stout/os/windows/fd.hpp (line 86) <https://reviews.apache.org/r/54591/#comment235942> In `crt`, why not check the `type_` here and `abort` if the type is not compatible with what is requested, sort of like how we do in `Try`? It seems like it's better to replace a subtle error with an obvious one. I'm not sure if this also makes sense for the `operator`s below, too? 3rdparty/stout/include/stout/os/windows/fd.hpp (line 306) <https://reviews.apache.org/r/54591/#comment235944> I'm a bit confused about the conversion logic here... if `left` is a CRT type, can't we just `static_cast<HANDLE>(left)` and compare that to the right? What am I missing? Also just so I'm clear: your comment above is saying that the check of `< 0` is just because `left` is signed, while `right` is unsigned, so they can't be equal in this case? Is it appropriate to do a `static_assert` to make sure `HANDLE` is unsigned in the future, too? 3rdparty/stout/include/stout/os/windows/fd.hpp (line 311) <https://reviews.apache.org/r/54591/#comment235943> Just for my own education, we are doing a `reinterpret_cast` here? Can we not just `static_cast<HANDLE>`? - Alex Clemmer On Feb. 5, 2017, 1:36 a.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54591/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2017, 1:36 a.m.) > > > Review request for mesos, Daniel Pravat and Joris Van Remoortere. > > > Repository: mesos > > > Description > ------- > > In POSIX the socket, pipe and a file are represented by the `int` type. > In Windows: > - A socket is kept in a `SOCKET` type (64 bit wide) > - A pipe or a WinAPI file descriptor in a `HANDLE` (64 bit wide) > - A CRT file descriptor in an `int` > > The `WindowsFD` class is a type that brings all of these things > together and behaves analogously to an `int` in POSIX. > > > Diffs > ----- > > 3rdparty/stout/include/stout/os.hpp > ed6fec3ac1c1f9dfb0585178401f4b552822a0a1 > 3rdparty/stout/include/stout/os/int_fd.hpp PRE-CREATION > 3rdparty/stout/include/stout/os/windows/fd.hpp PRE-CREATION > > Diff: https://reviews.apache.org/r/54591/diff/ > > > Testing > ------- > > > Thanks, > > Michael Park > >
