0
0
mirror of https://github.com/chromium/crashpad.git synced 2025-03-19 09:53:47 +00:00

214 lines
5.8 KiB
C++
Raw Normal View History

// Copyright 2014 The Crashpad Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#include "util/file/file_io.h"
#include <functional>
#include "base/check_op.h"
#include "base/logging.h"
#include "base/numerics/safe_conversions.h"
namespace crashpad {
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
namespace {
FileOperationResult FileIORead(FileHandle file,
bool can_log,
void* buffer,
size_t size) {
FileOperationResult rv = ReadFile(file, buffer, size);
if (rv < 0) {
PLOG_IF(ERROR, can_log) << internal::kNativeReadFunctionName;
return -1;
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
}
return rv;
}
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
class FileIOWriteAll final : public internal::WriteAllInternal {
public:
explicit FileIOWriteAll(FileHandle file) : WriteAllInternal(), file_(file) {}
FileIOWriteAll(const FileIOWriteAll&) = delete;
FileIOWriteAll& operator=(const FileIOWriteAll&) = delete;
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
~FileIOWriteAll() {}
private:
// WriteAllInternal:
FileOperationResult Write(const void* buffer, size_t size) override {
return internal::NativeWriteFile(file_, buffer, size);
}
FileHandle file_;
};
FileOperationResult ReadUntil(
std::function<FileOperationResult(void*, size_t)> read_function,
void* buffer,
size_t size) {
// Ensure bytes read fit within int32_t::max to make sure that they also fit
// into FileOperationResult on all platforms.
DCHECK_LE(size, size_t{std::numeric_limits<int32_t>::max()});
uintptr_t buffer_int = reinterpret_cast<uintptr_t>(buffer);
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
size_t total_bytes = 0;
size_t remaining = size;
while (remaining > 0) {
const FileOperationResult bytes_read =
read_function(reinterpret_cast<char*>(buffer_int), remaining);
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
if (bytes_read < 0) {
return bytes_read;
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
}
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
DCHECK_LE(static_cast<size_t>(bytes_read), remaining);
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
if (bytes_read == 0) {
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
break;
}
buffer_int += bytes_read;
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
remaining -= bytes_read;
total_bytes += bytes_read;
}
return total_bytes;
}
} // namespace
namespace internal {
bool ReadExactly(
std::function<FileOperationResult(bool, void*, size_t)> read_function,
bool can_log,
void* buffer,
size_t size) {
const FileOperationResult result =
ReadUntil(std::bind_front(read_function, can_log), buffer, size);
if (result < 0) {
return false;
}
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
if (static_cast<size_t>(result) != size) {
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
LOG_IF(ERROR, can_log) << "ReadExactly: expected " << size << ", observed "
<< result;
return false;
}
return true;
}
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
bool WriteAllInternal::WriteAll(const void* buffer, size_t size) {
uintptr_t buffer_int = reinterpret_cast<uintptr_t>(buffer);
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
while (size > 0) {
FileOperationResult bytes_written =
Write(reinterpret_cast<const char*>(buffer_int), size);
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
if (bytes_written < 0) {
return false;
}
DCHECK_NE(bytes_written, 0);
buffer_int += bytes_written;
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
size -= bytes_written;
}
return true;
}
} // namespace internal
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
bool ReadFileExactly(FileHandle file, void* buffer, size_t size) {
return internal::ReadExactly(
std::bind_front(&FileIORead, file), false, buffer, size);
}
FileOperationResult ReadFileUntil(FileHandle file, void* buffer, size_t size) {
return ReadUntil(std::bind_front(&FileIORead, file, false), buffer, size);
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
}
bool LoggingReadFileExactly(FileHandle file, void* buffer, size_t size) {
return internal::ReadExactly(
std::bind_front(&FileIORead, file), true, buffer, size);
}
FileOperationResult LoggingReadFileUntil(FileHandle file,
void* buffer,
size_t size) {
return ReadUntil(std::bind_front(&FileIORead, file, true), buffer, size);
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
}
bool WriteFile(FileHandle file, const void* buffer, size_t size) {
FileIOWriteAll write_all(file);
return write_all.WriteAll(buffer, size);
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
}
bool LoggingWriteFile(FileHandle file, const void* buffer, size_t size) {
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
if (!WriteFile(file, buffer, size)) {
PLOG(ERROR) << internal::kNativeWriteFunctionName;
return false;
}
return true;
}
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
void CheckedReadFileExactly(FileHandle file, void* buffer, size_t size) {
CHECK(LoggingReadFileExactly(file, buffer, size));
}
void CheckedWriteFile(FileHandle file, const void* buffer, size_t size) {
CHECK(LoggingWriteFile(file, buffer, size));
}
void CheckedReadFileAtEOF(FileHandle file) {
char c;
FileOperationResult rv = ReadFile(file, &c, 1);
if (rv < 0) {
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
PCHECK(rv == 0) << internal::kNativeReadFunctionName;
} else {
util/file: Handle oversized reads and writes gracefully file_io and the FileReader family had a few loose ends regarding big reads and writes. It’s not likely that we’ve experienced these conditions yet, but they’d be likely to appear in a potential future involving full memory dumps. This specifies the behavior with large reads and writes, consolidates some logic, and improves some interfaces. ReadFile() should always return without retrying after a short read, and in fact does return after short reads since 00b64427523b. It is straightforward to limit the maximum read size based on a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. In contrast, WriteFile() should always retry after a short write, including a write shortened because of a parameter limitation of the underlying operation, or a limitation of the type used for FileOperationResult. This allows its return value to be simplified to a “bool”. The platform-specific WriteFile() code has been moved to internal::NativeWriteFile(), and the platform-independent loop that retries following a short write has been refactored into internal::WriteAllInternal so that it can be used by a new test. The platform-agnostic ReadFileExactlyInternal() implementation has been refactored into internal::ReadExactlyInternal so that it can be used by a new test and by FileReaderInterface::ReadExactly(), which had a nearly identical implementation. Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_* Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864 Reviewed-on: https://chromium-review.googlesource.com/456824 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
CHECK_EQ(rv, 0) << internal::kNativeReadFunctionName;
}
}
bool LoggingReadToEOF(FileHandle file, std::string* contents) {
char buffer[4096];
FileOperationResult rv;
std::string local_contents;
while ((rv = ReadFile(file, buffer, sizeof(buffer))) > 0) {
DCHECK_LE(static_cast<size_t>(rv), sizeof(buffer));
local_contents.append(buffer, rv);
}
if (rv < 0) {
PLOG(ERROR) << internal::kNativeReadFunctionName;
return false;
}
contents->swap(local_contents);
return true;
}
bool LoggingReadEntireFile(const base::FilePath& path, std::string* contents) {
ScopedFileHandle handle(LoggingOpenFileForRead(path));
if (!handle.is_valid()) {
return false;
}
return LoggingReadToEOF(handle.get(), contents);
}
void CheckedCloseFile(FileHandle file) {
CHECK(LoggingCloseFile(file));
}
} // namespace crashpad