Cross platform low level file IO wrappers

util/file/file_io_win.cc

Index: util/file/file_io_win.cc
diff --git a/util/numeric/in_range_cast.h b/util/file/file_io_win.cc
similarity index 42%
copy from util/numeric/in_range_cast.h
copy to util/file/file_io_win.cc
index 3dba10afa16016bb7149cd1fa7b4ae14c72cfca2..de13219c0f287c516abea6efeaba8ffaef178c26 100644
--- a/util/numeric/in_range_cast.h
+++ b/util/file/file_io_win.cc
@@ -12,33 +12,44 @@
 // See the License for the specific language governing permissions and
 // limitations under the License.
 
-#ifndef CRASHPAD_UTIL_NUMERIC_IN_RANGE_CAST_H_
-#define CRASHPAD_UTIL_NUMERIC_IN_RANGE_CAST_H_
+#include "util/file/file_io.h"
 
 #include "base/logging.h"
 #include "base/numerics/safe_conversions.h"
 
 namespace crashpad {
 
-//! \brief Casts to a different type if it can be done without data loss,
-//!     logging a warning message and returing a default value otherwise.
-//!
-//! \param[in] source The value to convert and return.
-//! \param[in] default_value The default value to return, in the event that \a
-//!     source cannot be represented in the destination type.
-//!
-//! \return \a source if it can be represented in the destination type,
-//!     otherwise \a default_value.
-template <typename Destination, typename Source>
-Destination InRangeCast(Source source, Destination default_value) {
-  if (base::IsValueInRangeForNumericType<Destination>(source)) {
-    return static_cast<Destination>(source);
-  }
-
-  LOG(WARNING) << "value " << source << " out of range";
-  return static_cast<Destination>(default_value);
+// TODO(scottmg): Handle > DWORD sized writes if necessary.
+
+ssize_t ReadFile(FileHandle file, void* buffer, size_t size) {
+  DWORD size_dword = base::checked_cast<DWORD>(size);
+  DWORD total_read = 0;
+  BOOL success;
+  do {
+    DWORD bytes_read;
+    success = ::ReadFile(file, buffer, size_dword, &bytes_read, nullptr);

[Mark Mentovai, 2014/12/17 01:05:24]

On the second pass, buffer needs to point beyond its beginning by total_read
bytes, and size_dword needs to be decreased by total_read bytes. Take a look at
the trio of increments/decrements that the POSIX implementation does.

[scottmg, 2014/12/17 01:50:27]

Oh boy! Hopefully tests would have saved me eventually. Done.

+    if (!success && GetLastError() != ERROR_MORE_DATA)

[Mark Mentovai, 2014/12/17 01:05:24]

ReadFile()’s docs say that you’ll get ERROR_MORE_DATA for a pipe read in message
mode. What if it’s a stream-type pipe? I’m not sure if you’ll get an error or if
you’ll get success with fewer bytes_read than you asked for. I haven’t found
anything online that really answers the question. We should probably just test
it and see, that should be easy enough.

Learning a whole lot about Windows IPC today!

[scottmg, 2014/12/17 01:50:28]

Raymond gets upset when Windows programmers poke and infer as "documented
behaviour". :) More seriously, it's the sort of thing that tends to vary from
XP-to-recent, so testing can be tricky.

From
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365605%28v=vs.85%29...

"""
To create the pipe handle in byte-read mode, specify PIPE_READMODE_BYTE or use
the default value. Data is read from the pipe as a stream of bytes. A read
operation is completed successfully when all available bytes in the pipe are
read or when the specified number of bytes is read.
"""

So in that mode, "all available bytes in the pipe are read" sounds like success
with fewer bytes than requested. So, the modified loop style that matches the
POSIX one should handle this case.

ReadFile docs mention a success case for 0 bytes read:

"""
If the lpNumberOfBytesRead parameter is zero when ReadFile returns TRUE on a
pipe, the other end of the pipe called the WriteFile function with
nNumberOfBytesToWrite set to zero.
"""

That doesn't correspond to a complete read or EOF, so I'll leave that as
continuing to loop for now, rather than returning.
Maybe we can do some COM tomorrow!

[Mark Mentovai, 2014/12/17 05:39:16]

scottmg wrote:
I can’t wait!

+      return -1;
+    total_read += bytes_read;
+  } while (!success);
+  return total_read;
 }
 
-}  // namespace crashpad
+ssize_t WriteFile(FileHandle file, const void* buffer, size_t size) {
+  // TODO(scottmg): This might need to handle the limit for pipes across a
+  // network in the future.
+  DWORD size_dword = base::checked_cast<DWORD>(size);
+  DWORD bytes_written;
+  BOOL rv = ::WriteFile(file, buffer, size_dword, &bytes_written, nullptr);

[Mark Mentovai, 2014/12/17 01:05:24]

WriteFile()’s docs aren’t 100% convincing about short writes. They say that it
can return when “A read operation releases buffer space on the read end of the
pipe (if the write was blocked).” It’s not very explicit about what happens if
the pipe is full and the reader frees up space by reading less than the writer
is trying to write.

http://blogs.msdn.com/b/oldnewthing/archive/2011/07/07/10183884.aspx clears it
up, and it says that WriteFile() will keep on blocking until it’s able to put
everything into the pipe. Partial blocking writes can’t happen. I think we can
trust Raymond Chen on this…

[scottmg, 2014/12/17 01:50:28]

SG. The link above is also clear that it cannot succeed until all bytes are
written.

+  if (!rv)
+    return -1;
+  return bytes_written;

[Mark Mentovai, 2014/12/17 01:05:24]

…so let’s make it explicit and [D]CHECK_EQ(bytes_written, size_dword) before
returning here.

[scottmg, 2014/12/17 01:50:28]

Done.

+}
 
-#endif  // CRASHPAD_UTIL_NUMERIC_IN_RANGE_CAST_H_
+bool LoggingCloseFile(FileHandle file) {
+  BOOL rv = CloseHandle(file);
+  PLOG_IF(ERROR, !rv) << "CloseHandle";
+  return rv;
+}
+
+}  // namespace crashpad