> On April 6, 2018, 4:13 p.m., Andrew Schwartzmeyer wrote:
> > 3rdparty/stout/include/stout/os/read.hpp
> > Lines 117-127 (patched)
> > <https://reviews.apache.org/r/66431/diff/3/?file=1993497#file1993497line118>
> >
> >     I can't find much information on the implementation detailfs of 
> > `std::wifstream` in Visual C++. I'd like to be certain that it uses 
> > `CreateFileW` to open a handle, in which case this long path will work.
> >     
> >     I'm also not certain if we need to use `std::wifstream`; we could use 
> > `std::ifstream file(stringify(longpath.data()))` and avoid the `stringify` 
> > of the file contents (which we probably want to avoid).
> >     
> >     Thoughts?
> 
> Akash Gupta wrote:
>     I think `std::wifstream` is for the file contents instead of the file 
> name. Just using `std::ifstream` compiles for me.
> 
> Akash Gupta wrote:
>     MSVC++ has a custom ctor for wchar_t path names here: 
> https://msdn.microsoft.com/en-us/library/a33ahe62.aspx#basic_fstream__basic_fstream
>     
>     It's not part of the regular C++ standard 
> (http://en.cppreference.com/w/cpp/io/basic_fstream/basic_fstream), so I think 
> the proper stream is to use the regular `ifstream` with MSVC++ custom 
> `wchar_t` ctor.

Ah yup. I misread the docs. There is a `std::wifstream` type-def'ed in MSVC to 
be an `ifstream` templated on `wchar_t`... _but also_ `ifstream` and the others 
have extra `wchar_t` ctors in MSVC. Updating...


- Andrew


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


On April 6, 2018, 4:11 p.m., Andrew Schwartzmeyer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66431/
> -----------------------------------------------------------
> 
> (Updated April 6, 2018, 4:11 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8676
>     https://issues.apache.org/jira/browse/MESOS-8676
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This can eventually support overlapped I/O.
> 
> The Windows API `ReadFile()` returns an error if the pipe is broken,
> where `_read()` did not, but this is not an error for us as the data
> is still read correctly. So we ignore it.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/stout/os/read.hpp 
> 49878e499209fa2f91fede0ebdabb8f088a9d018 
>   3rdparty/stout/include/stout/os/windows/read.hpp 
> 8047ad590fcc46d3ec46b551472d8c518ae49cc1 
> 
> 
> Diff: https://reviews.apache.org/r/66431/diff/3/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Reply via email to