3party/crashpad
0
0
Fork 0
mirror of https://github.com/chromium/crashpad.git synced 2025-01-01 02:27:50 +08:00
Code Issues Projects Releases Wiki Activity
crashpad/util/file/file_io_test.cc

700 lines
25 KiB
C++
Raw Normal View History

Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
// Copyright 2015 The Crashpad Authors. All rights reserved.
//
// 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"
Remove WeakStdioFileReader and WeakStdioFileWriter These classes were a bit of a hack, and one of the the reasons that WeakStdioFileReader was introduced, accurate detection of EOF when stdin is a terminal, will be obsolete once https://chromium-review.googlesource.com/456676/ lands. In fact, WeakStdioFileReader didn’t even work properly for this purpose on Windows. Use WeakFile{Reader,Writer} in place of these classes (there were only two use sites). Provide a StdioFileHandle() function to access the proper values to use as a FileHandle for native file I/O given each OS’ own interface. Change-Id: I35e8d49982162bb9813855f41739cc77597ea74d Reviewed-on: https://chromium-review.googlesource.com/456358 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 16:15:54 -04:00
#include <stdio.h>
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
#include <limits>
#include <type_traits>
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
#include "base/atomicops.h"
#include "base/files/file_path.h"
Use base/macros.h instead of base/basictypes.h This was done in Chromium’s local copy of Crashpad in 562827afb599. This change is similar to that one, except more care was taken to avoid including headers from a .cc or _test.cc when already included by the associated .h. Rather than using <stddef.h> for size_t, Crashpad has always used <sys/types.h>, so that’s used here as well. This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc, which removes base/basictypes.h. e128dcf10122 Remove base/move.h; use std::move() instead of Pass() 8a2363f486e3 Move basictypes.h to macros.h R=avi@chromium.org Review URL: https://codereview.chromium.org/1566713002 .
2016-01-06 12:22:50 -05:00
#include "base/macros.h"
Use base::size where appropriate, and ArraySize elsewhere This is a follow-up to c8a016b99d97, following the post-landing discussion at https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7 base::size, and std::size that will eventually replace it when C++17 is assured, does not allow the size of non-static data members to be taken in constant expression context. The remaining uses of ArraySize are in: minidump/minidump_exception_writer.cc (×1) minidump/minidump_system_info_writer.cc (×2, also uses base::size) snapshot/cpu_context.cc (×4, also uses base::size) util/misc/arraysize_test.cc (×10, of course) The first of these occurs when initializing a constexpr variable. All others are in expressions used with static_assert. Includes: Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao f701716d9546 Add Windows ARM64 build target to mini_chromium 87a95a3d6ac2 Remove the arraysize macro 1f7255ead1f7 Placate MSVC in areas of base::size usage 737433ebade4 Add cast Bug: chromium:837308 Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19 Reviewed-on: https://chromium-review.googlesource.com/c/1396108 Commit-Queue: Mark Mentovai <mark@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org>
2019-01-04 16:57:57 -05:00
#include "base/stl_util.h"
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
#include "gmock/gmock.h"
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
#include "gtest/gtest.h"
test: Move util/test to its own top-level directory, test. After 9e79ea1da719, it no longer makes sense for crashpad_util_test_lib to “hide” in util/util_test.gyp. All of util/test is moved to its own top-level directory, test, which all other test code is allowed to depend on. test, too, is allowed to depend on all other non-test code. In a future change, when crashpad_util_test_lib gains a dependency on crashpad_client, it won’t look so weird for something in util (even though it’s in util/test) to depend on something in client, because the thing that needs to depend on client will live in test, not util. BUG=crashpad:33 R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1051533002
2015-03-31 17:44:14 -04:00
#include "test/errors.h"
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
#include "test/file.h"
test: Move util/test to its own top-level directory, test. After 9e79ea1da719, it no longer makes sense for crashpad_util_test_lib to “hide” in util/util_test.gyp. All of util/test is moved to its own top-level directory, test, which all other test code is allowed to depend on. test, too, is allowed to depend on all other non-test code. In a future change, when crashpad_util_test_lib gains a dependency on crashpad_client, it won’t look so weird for something in util (even though it’s in util/test) to depend on something in client, because the thing that needs to depend on client will live in test, not util. BUG=crashpad:33 R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1051533002
2015-03-31 17:44:14 -04:00
#include "test/scoped_temp_dir.h"
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
#include "util/misc/implicit_cast.h"
Move thread from test/ to util/thread/. BUG= R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1134943003
2015-05-13 14:05:57 -04:00
#include "util/thread/thread.h"
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
namespace crashpad {
namespace test {
namespace {
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
using testing::_;
using testing::InSequence;
using testing::Return;
class MockReadExactly : public internal::ReadExactlyInternal {
public:
MockReadExactly() : ReadExactlyInternal() {}
~MockReadExactly() {}
// Since it’s more convenient for the test to use uintptr_t than void*,
// ReadExactlyInt() and ReadInt() adapt the types.
bool ReadExactlyInt(uintptr_t data, size_t size, bool can_log) {
return ReadExactly(reinterpret_cast<void*>(data), size, can_log);
}
MOCK_METHOD3(ReadInt, FileOperationResult(uintptr_t, size_t, bool));
// ReadExactlyInternal:
FileOperationResult Read(void* data, size_t size, bool can_log) {
return ReadInt(reinterpret_cast<uintptr_t>(data), size, can_log);
}
private:
DISALLOW_COPY_AND_ASSIGN(MockReadExactly);
};
TEST(FileIO, ReadExactly_Zero) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(_, _, false)).Times(0);
EXPECT_TRUE(read_exactly.ReadExactlyInt(100, 0, false));
}
TEST(FileIO, ReadExactly_SingleSmallSuccess) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(1000, 1, false)).WillOnce(Return(1));
EXPECT_TRUE(read_exactly.ReadExactlyInt(1000, 1, false));
}
TEST(FileIO, ReadExactly_SingleSmallSuccessCanLog) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(1000, 1, true)).WillOnce(Return(1));
EXPECT_TRUE(read_exactly.ReadExactlyInt(1000, 1, true));
}
TEST(FileIO, ReadExactly_SingleSmallFailure) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(1000, 1, false)).WillOnce(Return(-1));
EXPECT_FALSE(read_exactly.ReadExactlyInt(1000, 1, false));
}
TEST(FileIO, ReadExactly_SingleSmallFailureCanLog) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(1000, 1, true)).WillOnce(Return(-1));
EXPECT_FALSE(read_exactly.ReadExactlyInt(1000, 1, true));
}
TEST(FileIO, ReadExactly_DoubleSmallSuccess) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(0x1000, 2, false)).WillOnce(Return(1));
EXPECT_CALL(read_exactly, ReadInt(0x1001, 1, false)).WillOnce(Return(1));
EXPECT_TRUE(read_exactly.ReadExactlyInt(0x1000, 2, false));
}
TEST(FileIO, ReadExactly_DoubleSmallShort) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(0x20000, 2, false)).WillOnce(Return(1));
EXPECT_CALL(read_exactly, ReadInt(0x20001, 1, false)).WillOnce(Return(0));
EXPECT_FALSE(read_exactly.ReadExactlyInt(0x20000, 2, false));
}
TEST(FileIO, ReadExactly_DoubleSmallShortCanLog) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(0x20000, 2, true)).WillOnce(Return(1));
EXPECT_CALL(read_exactly, ReadInt(0x20001, 1, true)).WillOnce(Return(0));
EXPECT_FALSE(read_exactly.ReadExactlyInt(0x20000, 2, true));
}
TEST(FileIO, ReadExactly_Medium) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(0x80000000, 0x20000000, false))
.WillOnce(Return(0x10000000));
EXPECT_CALL(read_exactly, ReadInt(0x90000000, 0x10000000, false))
.WillOnce(Return(0x8000000));
EXPECT_CALL(read_exactly, ReadInt(0x98000000, 0x8000000, false))
.WillOnce(Return(0x4000000));
EXPECT_CALL(read_exactly, ReadInt(0x9c000000, 0x4000000, false))
.WillOnce(Return(0x2000000));
EXPECT_CALL(read_exactly, ReadInt(0x9e000000, 0x2000000, false))
.WillOnce(Return(0x1000000));
EXPECT_CALL(read_exactly, ReadInt(0x9f000000, 0x1000000, false))
.WillOnce(Return(0x800000));
EXPECT_CALL(read_exactly, ReadInt(0x9f800000, 0x800000, false))
.WillOnce(Return(0x400000));
EXPECT_CALL(read_exactly, ReadInt(0x9fc00000, 0x400000, false))
.WillOnce(Return(0x200000));
EXPECT_CALL(read_exactly, ReadInt(0x9fe00000, 0x200000, false))
.WillOnce(Return(0x100000));
EXPECT_CALL(read_exactly, ReadInt(0x9ff00000, 0x100000, false))
.WillOnce(Return(0x80000));
EXPECT_CALL(read_exactly, ReadInt(0x9ff80000, 0x80000, false))
.WillOnce(Return(0x40000));
EXPECT_CALL(read_exactly, ReadInt(0x9ffc0000, 0x40000, false))
.WillOnce(Return(0x20000));
EXPECT_CALL(read_exactly, ReadInt(0x9ffe0000, 0x20000, false))
.WillOnce(Return(0x10000));
EXPECT_CALL(read_exactly, ReadInt(0x9fff0000, 0x10000, false))
.WillOnce(Return(0x8000));
EXPECT_CALL(read_exactly, ReadInt(0x9fff8000, 0x8000, false))
.WillOnce(Return(0x4000));
EXPECT_CALL(read_exactly, ReadInt(0x9fffc000, 0x4000, false))
.WillOnce(Return(0x2000));
EXPECT_CALL(read_exactly, ReadInt(0x9fffe000, 0x2000, false))
.WillOnce(Return(0x1000));
EXPECT_CALL(read_exactly, ReadInt(0x9ffff000, 0x1000, false))
.WillOnce(Return(0x800));
EXPECT_CALL(read_exactly, ReadInt(0x9ffff800, 0x800, false))
.WillOnce(Return(0x400));
EXPECT_CALL(read_exactly, ReadInt(0x9ffffc00, 0x400, false))
.WillOnce(Return(0x200));
EXPECT_CALL(read_exactly, ReadInt(0x9ffffe00, 0x200, false))
.WillOnce(Return(0x100));
EXPECT_CALL(read_exactly, ReadInt(0x9fffff00, 0x100, false))
.WillOnce(Return(0x80));
EXPECT_CALL(read_exactly, ReadInt(0x9fffff80, 0x80, false))
.WillOnce(Return(0x40));
EXPECT_CALL(read_exactly, ReadInt(0x9fffffc0, 0x40, false))
.WillOnce(Return(0x20));
EXPECT_CALL(read_exactly, ReadInt(0x9fffffe0, 0x20, false))
.WillOnce(Return(0x10));
EXPECT_CALL(read_exactly, ReadInt(0x9ffffff0, 0x10, false))
.WillOnce(Return(0x8));
EXPECT_CALL(read_exactly, ReadInt(0x9ffffff8, 0x8, false))
.WillOnce(Return(0x4));
EXPECT_CALL(read_exactly, ReadInt(0x9ffffffc, 0x4, false))
.WillOnce(Return(0x2));
EXPECT_CALL(read_exactly, ReadInt(0x9ffffffe, 0x2, false))
.WillOnce(Return(0x1));
EXPECT_CALL(read_exactly, ReadInt(0x9fffffff, 0x1, false))
.WillOnce(Return(0x1));
EXPECT_TRUE(read_exactly.ReadExactlyInt(0x80000000, 0x20000000, false));
}
TEST(FileIO, ReadExactly_LargeSuccess) {
MockReadExactly read_exactly;
InSequence in_sequence;
constexpr size_t max = std::numeric_limits<uint32_t>::max();
constexpr size_t increment = std::numeric_limits<int32_t>::max();
EXPECT_CALL(read_exactly, ReadInt(0, max, false)).WillOnce(Return(increment));
EXPECT_CALL(read_exactly, ReadInt(increment, max - increment, false))
.WillOnce(Return(increment));
EXPECT_CALL(read_exactly, ReadInt(2 * increment, 1, false))
.WillOnce(Return(1));
EXPECT_TRUE(read_exactly.ReadExactlyInt(0, max, false));
}
TEST(FileIO, ReadExactly_LargeShort) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(0, 0xffffffff, false))
.WillOnce(Return(0x7fffffff));
EXPECT_CALL(read_exactly, ReadInt(0x7fffffff, 0x80000000, false))
.WillOnce(Return(0x10000000));
EXPECT_CALL(read_exactly, ReadInt(0x8fffffff, 0x70000000, false))
.WillOnce(Return(0));
EXPECT_FALSE(read_exactly.ReadExactlyInt(0, 0xffffffff, false));
}
TEST(FileIO, ReadExactly_LargeFailure) {
MockReadExactly read_exactly;
InSequence in_sequence;
EXPECT_CALL(read_exactly, ReadInt(0, 0xffffffff, false))
.WillOnce(Return(0x7fffffff));
EXPECT_CALL(read_exactly, ReadInt(0x7fffffff, 0x80000000, false))
.WillOnce(Return(-1));
EXPECT_FALSE(read_exactly.ReadExactlyInt(0, 0xffffffff, false));
}
TEST(FileIO, ReadExactly_TripleMax) {
MockReadExactly read_exactly;
InSequence in_sequence;
constexpr size_t max = std::numeric_limits<size_t>::max();
constexpr size_t increment =
std::numeric_limits<std::make_signed<size_t>::type>::max();
EXPECT_CALL(read_exactly, ReadInt(0, max, false)).WillOnce(Return(increment));
EXPECT_CALL(read_exactly, ReadInt(increment, max - increment, false))
.WillOnce(Return(increment));
EXPECT_CALL(read_exactly, ReadInt(2 * increment, 1, false))
.WillOnce(Return(1));
EXPECT_TRUE(read_exactly.ReadExactlyInt(0, max, false));
}
class MockWriteAll : public internal::WriteAllInternal {
public:
MockWriteAll() : WriteAllInternal() {}
~MockWriteAll() {}
// Since it’s more convenient for the test to use uintptr_t than const void*,
// WriteAllInt() and WriteInt() adapt the types.
bool WriteAllInt(uintptr_t data, size_t size) {
return WriteAll(reinterpret_cast<const void*>(data), size);
}
MOCK_METHOD2(WriteInt, FileOperationResult(uintptr_t, size_t));
// WriteAllInternal:
FileOperationResult Write(const void* data, size_t size) {
return WriteInt(reinterpret_cast<uintptr_t>(data), size);
}
private:
DISALLOW_COPY_AND_ASSIGN(MockWriteAll);
};
TEST(FileIO, WriteAll_Zero) {
MockWriteAll write_all;
InSequence in_sequence;
EXPECT_CALL(write_all, WriteInt(_, _)).Times(0);
EXPECT_TRUE(write_all.WriteAllInt(100, 0));
}
TEST(FileIO, WriteAll_SingleSmallSuccess) {
MockWriteAll write_all;
InSequence in_sequence;
EXPECT_CALL(write_all, WriteInt(1000, 1)).WillOnce(Return(1));
EXPECT_TRUE(write_all.WriteAllInt(1000, 1));
}
TEST(FileIO, WriteAll_SingleSmallFailure) {
MockWriteAll write_all;
InSequence in_sequence;
EXPECT_CALL(write_all, WriteInt(1000, 1)).WillOnce(Return(-1));
EXPECT_FALSE(write_all.WriteAllInt(1000, 1));
}
TEST(FileIO, WriteAll_DoubleSmall) {
MockWriteAll write_all;
InSequence in_sequence;
EXPECT_CALL(write_all, WriteInt(0x1000, 2)).WillOnce(Return(1));
EXPECT_CALL(write_all, WriteInt(0x1001, 1)).WillOnce(Return(1));
EXPECT_TRUE(write_all.WriteAllInt(0x1000, 2));
}
TEST(FileIO, WriteAll_Medium) {
MockWriteAll write_all;
InSequence in_sequence;
EXPECT_CALL(write_all, WriteInt(0x80000000, 0x20000000))
.WillOnce(Return(0x10000000));
EXPECT_CALL(write_all, WriteInt(0x90000000, 0x10000000))
.WillOnce(Return(0x8000000));
EXPECT_CALL(write_all, WriteInt(0x98000000, 0x8000000))
.WillOnce(Return(0x4000000));
EXPECT_CALL(write_all, WriteInt(0x9c000000, 0x4000000))
.WillOnce(Return(0x2000000));
EXPECT_CALL(write_all, WriteInt(0x9e000000, 0x2000000))
.WillOnce(Return(0x1000000));
EXPECT_CALL(write_all, WriteInt(0x9f000000, 0x1000000))
.WillOnce(Return(0x800000));
EXPECT_CALL(write_all, WriteInt(0x9f800000, 0x800000))
.WillOnce(Return(0x400000));
EXPECT_CALL(write_all, WriteInt(0x9fc00000, 0x400000))
.WillOnce(Return(0x200000));
EXPECT_CALL(write_all, WriteInt(0x9fe00000, 0x200000))
.WillOnce(Return(0x100000));
EXPECT_CALL(write_all, WriteInt(0x9ff00000, 0x100000))
.WillOnce(Return(0x80000));
EXPECT_CALL(write_all, WriteInt(0x9ff80000, 0x80000))
.WillOnce(Return(0x40000));
EXPECT_CALL(write_all, WriteInt(0x9ffc0000, 0x40000))
.WillOnce(Return(0x20000));
EXPECT_CALL(write_all, WriteInt(0x9ffe0000, 0x20000))
.WillOnce(Return(0x10000));
EXPECT_CALL(write_all, WriteInt(0x9fff0000, 0x10000))
.WillOnce(Return(0x8000));
EXPECT_CALL(write_all, WriteInt(0x9fff8000, 0x8000)).WillOnce(Return(0x4000));
EXPECT_CALL(write_all, WriteInt(0x9fffc000, 0x4000)).WillOnce(Return(0x2000));
EXPECT_CALL(write_all, WriteInt(0x9fffe000, 0x2000)).WillOnce(Return(0x1000));
EXPECT_CALL(write_all, WriteInt(0x9ffff000, 0x1000)).WillOnce(Return(0x800));
EXPECT_CALL(write_all, WriteInt(0x9ffff800, 0x800)).WillOnce(Return(0x400));
EXPECT_CALL(write_all, WriteInt(0x9ffffc00, 0x400)).WillOnce(Return(0x200));
EXPECT_CALL(write_all, WriteInt(0x9ffffe00, 0x200)).WillOnce(Return(0x100));
EXPECT_CALL(write_all, WriteInt(0x9fffff00, 0x100)).WillOnce(Return(0x80));
EXPECT_CALL(write_all, WriteInt(0x9fffff80, 0x80)).WillOnce(Return(0x40));
EXPECT_CALL(write_all, WriteInt(0x9fffffc0, 0x40)).WillOnce(Return(0x20));
EXPECT_CALL(write_all, WriteInt(0x9fffffe0, 0x20)).WillOnce(Return(0x10));
EXPECT_CALL(write_all, WriteInt(0x9ffffff0, 0x10)).WillOnce(Return(0x8));
EXPECT_CALL(write_all, WriteInt(0x9ffffff8, 0x8)).WillOnce(Return(0x4));
EXPECT_CALL(write_all, WriteInt(0x9ffffffc, 0x4)).WillOnce(Return(0x2));
EXPECT_CALL(write_all, WriteInt(0x9ffffffe, 0x2)).WillOnce(Return(0x1));
EXPECT_CALL(write_all, WriteInt(0x9fffffff, 0x1)).WillOnce(Return(0x1));
EXPECT_TRUE(write_all.WriteAllInt(0x80000000, 0x20000000));
}
TEST(FileIO, WriteAll_LargeSuccess) {
MockWriteAll write_all;
InSequence in_sequence;
constexpr size_t max = std::numeric_limits<uint32_t>::max();
constexpr size_t increment = std::numeric_limits<int32_t>::max();
EXPECT_CALL(write_all, WriteInt(0, max)).WillOnce(Return(increment));
EXPECT_CALL(write_all, WriteInt(increment, max - increment))
.WillOnce(Return(increment));
EXPECT_CALL(write_all, WriteInt(2 * increment, 1)).WillOnce(Return(1));
EXPECT_TRUE(write_all.WriteAllInt(0, max));
}
TEST(FileIO, WriteAll_LargeFailure) {
MockWriteAll write_all;
InSequence in_sequence;
EXPECT_CALL(write_all, WriteInt(0, 0xffffffff)).WillOnce(Return(0x7fffffff));
EXPECT_CALL(write_all, WriteInt(0x7fffffff, 0x80000000)).WillOnce(Return(-1));
EXPECT_FALSE(write_all.WriteAllInt(0, 0xffffffff));
}
TEST(FileIO, WriteAll_TripleMax) {
MockWriteAll write_all;
InSequence in_sequence;
constexpr size_t max = std::numeric_limits<size_t>::max();
constexpr size_t increment =
std::numeric_limits<std::make_signed<size_t>::type>::max();
EXPECT_CALL(write_all, WriteInt(0, max)).WillOnce(Return(increment));
EXPECT_CALL(write_all, WriteInt(increment, max - increment))
.WillOnce(Return(increment));
EXPECT_CALL(write_all, WriteInt(2 * increment, 1)).WillOnce(Return(1));
EXPECT_TRUE(write_all.WriteAllInt(0, max));
}
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
void TestOpenFileForWrite(FileHandle (*opener)(const base::FilePath&,
FileWriteMode,
FilePermissions)) {
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
ScopedTempDir temp_dir;
base::FilePath file_path_1 =
temp_dir.path().Append(FILE_PATH_LITERAL("file_1"));
ASSERT_FALSE(FileExists(file_path_1));
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
ScopedFileHandle file_handle(opener(file_path_1,
FileWriteMode::kReuseOrFail,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_FALSE(FileExists(file_path_1));
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_1,
FileWriteMode::kCreateOrFail,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_1));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), 0);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_1,
FileWriteMode::kReuseOrCreate,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_1));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), 0);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
Use constexpr at function scope This is essentially based on a search for “^ *const [^*&]*=[^(]*$” Change-Id: Id571119d0b9a64c6f387eccd51cea7c9eb530e13 Reviewed-on: https://chromium-review.googlesource.com/585555 Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
2017-07-25 19:15:48 -04:00
constexpr char data = '%';
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(LoggingWriteFile(file_handle.get(), &data, sizeof(data)));
// Close file_handle to ensure that the write is flushed to disk.
file_handle.reset();
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), implicit_cast<FileOffset>(sizeof(data)));
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_1,
FileWriteMode::kReuseOrCreate,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_1));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), implicit_cast<FileOffset>(sizeof(data)));
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_1,
FileWriteMode::kCreateOrFail,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_1));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), implicit_cast<FileOffset>(sizeof(data)));
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_1,
FileWriteMode::kReuseOrFail,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_1));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), implicit_cast<FileOffset>(sizeof(data)));
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_1,
FileWriteMode::kTruncateOrCreate,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_1));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_1), 0);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
base::FilePath file_path_2 =
temp_dir.path().Append(FILE_PATH_LITERAL("file_2"));
ASSERT_FALSE(FileExists(file_path_2));
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_2,
FileWriteMode::kTruncateOrCreate,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_2));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_2), 0);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
base::FilePath file_path_3 =
temp_dir.path().Append(FILE_PATH_LITERAL("file_3"));
ASSERT_FALSE(FileExists(file_path_3));
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
file_handle.reset(opener(file_path_3,
FileWriteMode::kReuseOrCreate,
FilePermissions::kWorldReadable));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_NE(file_handle, kInvalidFileHandle);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
EXPECT_TRUE(FileExists(file_path_3));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(FileSize(file_path_3), 0);
Add FileWriteMode::kCreateOrFail BUG=crashpad:63 TEST=crashpad_util_test FileIO.OpenFileForWrite R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1390023002 .
2015-10-07 08:20:55 -04:00
}
Add non-logging OpenFileForWrite() and OpenFileForReadAndWrite() BUG=crashpad:63 TEST=crashpad_util_test FileIO.*OpenFileFor* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1395543002 .
2015-10-07 11:40:02 -04:00
TEST(FileIO, OpenFileForWrite) {
TestOpenFileForWrite(OpenFileForWrite);
}
TEST(FileIO, OpenFileForReadAndWrite) {
TestOpenFileForWrite(OpenFileForReadAndWrite);
}
TEST(FileIO, LoggingOpenFileForWrite) {
TestOpenFileForWrite(LoggingOpenFileForWrite);
}
TEST(FileIO, LoggingOpenFileForReadAndWrite) {
TestOpenFileForWrite(LoggingOpenFileForReadAndWrite);
}
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
enum class ReadOrWrite : bool {
kRead,
kWrite,
};
void FileShareModeTest(ReadOrWrite first, ReadOrWrite second) {
ScopedTempDir temp_dir;
base::FilePath shared_file =
temp_dir.path().Append(FILE_PATH_LITERAL("shared_file"));
{
// Create an empty file to work on.
ScopedFileHandle create(
LoggingOpenFileForWrite(shared_file,
FileWriteMode::kCreateOrFail,
FilePermissions::kOwnerOnly));
}
auto handle1 = ScopedFileHandle(
(first == ReadOrWrite::kRead)
? LoggingOpenFileForRead(shared_file)
: LoggingOpenFileForWrite(shared_file,
FileWriteMode::kReuseOrCreate,
FilePermissions::kOwnerOnly));
ASSERT_NE(handle1, kInvalidFileHandle);
auto handle2 = ScopedFileHandle(
(second == ReadOrWrite::kRead)
? LoggingOpenFileForRead(shared_file)
: LoggingOpenFileForWrite(shared_file,
FileWriteMode::kReuseOrCreate,
FilePermissions::kOwnerOnly));
EXPECT_NE(handle2, kInvalidFileHandle);
EXPECT_NE(handle1.get(), handle2.get());
}
TEST(FileIO, FileShareMode_Read_Read) {
FileShareModeTest(ReadOrWrite::kRead, ReadOrWrite::kRead);
}
TEST(FileIO, FileShareMode_Read_Write) {
FileShareModeTest(ReadOrWrite::kRead, ReadOrWrite::kWrite);
}
TEST(FileIO, FileShareMode_Write_Read) {
FileShareModeTest(ReadOrWrite::kWrite, ReadOrWrite::kRead);
}
TEST(FileIO, FileShareMode_Write_Write) {
FileShareModeTest(ReadOrWrite::kWrite, ReadOrWrite::kWrite);
}
fuchsia: Compile out LoggingLock/UnlockFile, add DCHECKs to Settings Fuchsia does not currently support any sort of file locking. Until a lock server can be implemented, compile out the calls to flock(). In the one current non-test user of locking (Settings) add a pseudo-implementation that will DCHECK if there is ever contention on the lock. Bug: crashpad:217, crashpad:196 Change-Id: Ifdf7e00886ad7e7778745f1ae8f0ce2a86f0ae3b Reviewed-on: https://chromium-review.googlesource.com/924312 Commit-Queue: Scott Graham <scottmg@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org>
2018-02-16 12:24:09 -08:00
// Fuchsia does not currently support any sort of file locking. See
// https://crashpad.chromium.org/bug/196 and
// https://crashpad.chromium.org/bug/217.
#if !defined(OS_FUCHSIA)
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
TEST(FileIO, MultipleSharedLocks) {
ScopedTempDir temp_dir;
base::FilePath shared_file =
temp_dir.path().Append(FILE_PATH_LITERAL("file_to_lock"));
{
// Create an empty file to lock.
ScopedFileHandle create(
LoggingOpenFileForWrite(shared_file,
FileWriteMode::kCreateOrFail,
FilePermissions::kOwnerOnly));
}
auto handle1 = ScopedFileHandle(LoggingOpenFileForRead(shared_file));
ASSERT_NE(handle1, kInvalidFileHandle);
EXPECT_TRUE(LoggingLockFile(handle1.get(), FileLocking::kShared));
auto handle2 = ScopedFileHandle(LoggingOpenFileForRead(shared_file));
ASSERT_NE(handle1, kInvalidFileHandle);
EXPECT_TRUE(LoggingLockFile(handle2.get(), FileLocking::kShared));
EXPECT_TRUE(LoggingUnlockFile(handle1.get()));
EXPECT_TRUE(LoggingUnlockFile(handle2.get()));
}
class LockingTestThread : public Thread {
public:
LockingTestThread()
: file_(), lock_type_(), iterations_(), actual_iterations_() {}
void Init(FileHandle file,
FileLocking lock_type,
int iterations,
base::subtle::Atomic32* actual_iterations) {
ASSERT_NE(file, kInvalidFileHandle);
file_ = ScopedFileHandle(file);
lock_type_ = lock_type;
iterations_ = iterations;
actual_iterations_ = actual_iterations;
}
private:
void ThreadMain() override {
for (int i = 0; i < iterations_; ++i) {
EXPECT_TRUE(LoggingLockFile(file_.get(), lock_type_));
base::subtle::NoBarrier_AtomicIncrement(actual_iterations_, 1);
EXPECT_TRUE(LoggingUnlockFile(file_.get()));
}
}
ScopedFileHandle file_;
FileLocking lock_type_;
int iterations_;
base::subtle::Atomic32* actual_iterations_;
DISALLOW_COPY_AND_ASSIGN(LockingTestThread);
};
void LockingTest(FileLocking main_lock, FileLocking other_locks) {
ScopedTempDir temp_dir;
base::FilePath shared_file =
temp_dir.path().Append(FILE_PATH_LITERAL("file_to_lock"));
{
// Create an empty file to lock.
ScopedFileHandle create(
LoggingOpenFileForWrite(shared_file,
FileWriteMode::kCreateOrFail,
FilePermissions::kOwnerOnly));
}
auto initial = ScopedFileHandle(
(main_lock == FileLocking::kShared)
? LoggingOpenFileForRead(shared_file)
: LoggingOpenFileForWrite(shared_file,
FileWriteMode::kReuseOrCreate,
FilePermissions::kOwnerOnly));
ASSERT_NE(initial, kInvalidFileHandle);
ASSERT_TRUE(LoggingLockFile(initial.get(), main_lock));
base::subtle::Atomic32 actual_iterations = 0;
LockingTestThread threads[20];
int expected_iterations = 0;
Use base::size where appropriate, and ArraySize elsewhere This is a follow-up to c8a016b99d97, following the post-landing discussion at https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7 base::size, and std::size that will eventually replace it when C++17 is assured, does not allow the size of non-static data members to be taken in constant expression context. The remaining uses of ArraySize are in: minidump/minidump_exception_writer.cc (×1) minidump/minidump_system_info_writer.cc (×2, also uses base::size) snapshot/cpu_context.cc (×4, also uses base::size) util/misc/arraysize_test.cc (×10, of course) The first of these occurs when initializing a constexpr variable. All others are in expressions used with static_assert. Includes: Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao f701716d9546 Add Windows ARM64 build target to mini_chromium 87a95a3d6ac2 Remove the arraysize macro 1f7255ead1f7 Placate MSVC in areas of base::size usage 737433ebade4 Add cast Bug: chromium:837308 Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19 Reviewed-on: https://chromium-review.googlesource.com/c/1396108 Commit-Queue: Mark Mentovai <mark@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org>
2019-01-04 16:57:57 -05:00
for (size_t index = 0; index < base::size(threads); ++index) {
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
int iterations_for_this_thread = static_cast<int>(index * 10);
threads[index].Init(
(other_locks == FileLocking::kShared)
? LoggingOpenFileForRead(shared_file)
: LoggingOpenFileForWrite(shared_file,
FileWriteMode::kReuseOrCreate,
FilePermissions::kOwnerOnly),
other_locks,
iterations_for_this_thread,
&actual_iterations);
expected_iterations += iterations_for_this_thread;
ASSERT_NO_FATAL_FAILURE(threads[index].Start());
}
base::subtle::Atomic32 result =
file_io_test: Use NoBarrier_Load() instead of Release_Load(). BUG=chromium:420970 TEST=util_test FileIO.*Exclusive* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1130403002
2015-05-08 14:15:11 -04:00
base::subtle::NoBarrier_Load(&actual_iterations);
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(result, 0);
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
ASSERT_TRUE(LoggingUnlockFile(initial.get()));
for (auto& t : threads)
t.Join();
file_io_test: Use NoBarrier_Load() instead of Release_Load(). BUG=chromium:420970 TEST=util_test FileIO.*Exclusive* R=scottmg@chromium.org Review URL: https://codereview.chromium.org/1130403002
2015-05-08 14:15:11 -04:00
result = base::subtle::NoBarrier_Load(&actual_iterations);
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(result, expected_iterations);
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
}
TEST(FileIO, ExclusiveVsExclusives) {
LockingTest(FileLocking::kExclusive, FileLocking::kExclusive);
}
TEST(FileIO, ExclusiveVsShareds) {
LockingTest(FileLocking::kExclusive, FileLocking::kShared);
}
TEST(FileIO, SharedVsExclusives) {
LockingTest(FileLocking::kShared, FileLocking::kExclusive);
}
fuchsia: Compile out LoggingLock/UnlockFile, add DCHECKs to Settings Fuchsia does not currently support any sort of file locking. Until a lock server can be implemented, compile out the calls to flock(). In the one current non-test user of locking (Settings) add a pseudo-implementation that will DCHECK if there is ever contention on the lock. Bug: crashpad:217, crashpad:196 Change-Id: Ifdf7e00886ad7e7778745f1ae8f0ce2a86f0ae3b Reviewed-on: https://chromium-review.googlesource.com/924312 Commit-Queue: Scott Graham <scottmg@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org>
2018-02-16 12:24:09 -08:00
#endif // !OS_FUCHSIA
Test first integration of UMA plumbing Add a first example of a UMA entry to have it available to try to plumb through to Chromium. Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the size of on disk file to report to UMA. Also rolls DEPS for mini_chromium to include: b5ec9ce Add stub versions of histogram_macros.h R=mark@chromium.org BUG=crashpad:100 Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821 Reviewed-on: https://chromium-review.googlesource.com/338821 Reviewed-by: Mark Mentovai <mark@chromium.org>
2016-09-01 17:01:31 -07:00
TEST(FileIO, FileSizeByHandle) {
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(LoggingFileSizeByHandle(kInvalidFileHandle), -1);
Test first integration of UMA plumbing Add a first example of a UMA entry to have it available to try to plumb through to Chromium. Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the size of on disk file to report to UMA. Also rolls DEPS for mini_chromium to include: b5ec9ce Add stub versions of histogram_macros.h R=mark@chromium.org BUG=crashpad:100 Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821 Reviewed-on: https://chromium-review.googlesource.com/338821 Reviewed-by: Mark Mentovai <mark@chromium.org>
2016-09-01 17:01:31 -07:00
ScopedTempDir temp_dir;
base::FilePath file_path =
temp_dir.path().Append(FILE_PATH_LITERAL("file_size"));
ScopedFileHandle file_handle(LoggingOpenFileForWrite(
file_path, FileWriteMode::kCreateOrFail, FilePermissions::kOwnerOnly));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
ASSERT_NE(file_handle.get(), kInvalidFileHandle);
EXPECT_EQ(LoggingFileSizeByHandle(file_handle.get()), 0);
Test first integration of UMA plumbing Add a first example of a UMA entry to have it available to try to plumb through to Chromium. Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the size of on disk file to report to UMA. Also rolls DEPS for mini_chromium to include: b5ec9ce Add stub versions of histogram_macros.h R=mark@chromium.org BUG=crashpad:100 Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821 Reviewed-on: https://chromium-review.googlesource.com/338821 Reviewed-by: Mark Mentovai <mark@chromium.org>
2016-09-01 17:01:31 -07:00
Standardize on static constexpr for arrays when possible This uses “static” at function scope to avoid making local copies, even in cases where the compiler can’t see that the local copy is unnecessary. “constexpr” adds additional safety in that it prevents global state from being initialized from any runtime dependencies, which would be undesirable. At namespace scope, “constexpr” is also used where appropriate. For the most part, this was a mechanical transformation for things matching '(^| )const [^=]*\['. Similar transformations could be applied to non-arrays in some cases, but there’s limited practical impact in most non-array cases relative to arrays, there are far more use sites, and much more manual intervention would be required. Change-Id: I3513b739ee8b0be026f8285475cddc5f9cc81152 Reviewed-on: https://chromium-review.googlesource.com/583997 Commit-Queue: Mark Mentovai <mark@chromium.org> Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
2017-07-25 13:34:04 -04:00
static constexpr char data[] = "zippyzap";
Test first integration of UMA plumbing Add a first example of a UMA entry to have it available to try to plumb through to Chromium. Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the size of on disk file to report to UMA. Also rolls DEPS for mini_chromium to include: b5ec9ce Add stub versions of histogram_macros.h R=mark@chromium.org BUG=crashpad:100 Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821 Reviewed-on: https://chromium-review.googlesource.com/338821 Reviewed-by: Mark Mentovai <mark@chromium.org>
2016-09-01 17:01:31 -07:00
ASSERT_TRUE(LoggingWriteFile(file_handle.get(), &data, sizeof(data)));
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(LoggingFileSizeByHandle(file_handle.get()), 9);
Test first integration of UMA plumbing Add a first example of a UMA entry to have it available to try to plumb through to Chromium. Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the size of on disk file to report to UMA. Also rolls DEPS for mini_chromium to include: b5ec9ce Add stub versions of histogram_macros.h R=mark@chromium.org BUG=crashpad:100 Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821 Reviewed-on: https://chromium-review.googlesource.com/338821 Reviewed-by: Mark Mentovai <mark@chromium.org>
2016-09-01 17:01:31 -07:00
}
Remove WeakStdioFileReader and WeakStdioFileWriter These classes were a bit of a hack, and one of the the reasons that WeakStdioFileReader was introduced, accurate detection of EOF when stdin is a terminal, will be obsolete once https://chromium-review.googlesource.com/456676/ lands. In fact, WeakStdioFileReader didn’t even work properly for this purpose on Windows. Use WeakFile{Reader,Writer} in place of these classes (there were only two use sites). Provide a StdioFileHandle() function to access the proper values to use as a FileHandle for native file I/O given each OS’ own interface. Change-Id: I35e8d49982162bb9813855f41739cc77597ea74d Reviewed-on: https://chromium-review.googlesource.com/456358 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 16:15:54 -04:00
FileHandle FileHandleForFILE(FILE* file) {
int fd = fileno(file);
#if defined(OS_POSIX)
return fd;
#elif defined(OS_WIN)
return reinterpret_cast<HANDLE>(_get_osfhandle(fd));
#else
#error Port
#endif
}
TEST(FileIO, StdioFileHandle) {
test: Use (actual, [un]expected) in gtest {ASSERT,EXPECT}_{EQ,NE} gtest used to require (expected, actual) ordering for arguments to EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify each side as “expected” or “actual.” Tests in Crashpad adhered to this traditional ordering. After a gtest change in February 2016, it is now agnostic with respect to the order of these arguments. This change mechanically updates all uses of these macros to (actual, expected) by reversing them. This provides consistency with our use of the logging CHECK_EQ and DCHECK_EQ macros, and makes for better readability by ordinary native speakers. The rough (but working!) conversion tool is https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py, and “git cl format” cleaned up its output. EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made a judgment that one side or the other needed to provide an “unexpected” value. Consequently, some code used (unexpected, actual) while other code used (actual, unexpected). For consistency with the new EXPECT_EQ and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE, this change also updates these use sites to (actual, unexpected) where one side can be called “unexpected” as, for example, std::string::npos can be. Unfortunately, this portion was a manual conversion. References: https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison https://github.com/google/googletest/commit/77d6b173380332b1c1bc540532641f410ec82d65 https://github.com/google/googletest/pull/713 Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3 Reviewed-on: https://chromium-review.googlesource.com/466727 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-04 00:35:21 -04:00
EXPECT_EQ(StdioFileHandle(StdioStream::kStandardInput),
FileHandleForFILE(stdin));
EXPECT_EQ(StdioFileHandle(StdioStream::kStandardOutput),
FileHandleForFILE(stdout));
EXPECT_EQ(StdioFileHandle(StdioStream::kStandardError),
FileHandleForFILE(stderr));
Remove WeakStdioFileReader and WeakStdioFileWriter These classes were a bit of a hack, and one of the the reasons that WeakStdioFileReader was introduced, accurate detection of EOF when stdin is a terminal, will be obsolete once https://chromium-review.googlesource.com/456676/ lands. In fact, WeakStdioFileReader didn’t even work properly for this purpose on Windows. Use WeakFile{Reader,Writer} in place of these classes (there were only two use sites). Provide a StdioFileHandle() function to access the proper values to use as a FileHandle for native file I/O given each OS’ own interface. Change-Id: I35e8d49982162bb9813855f41739cc77597ea74d Reviewed-on: https://chromium-review.googlesource.com/456358 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 16:15:54 -04:00
}
Add Locking calls to file_io.h plus implementations and test Towards removing use of open() with O_EXLOCK/O_SHLOCK in code used on non-BSD. Adds simple Thread abstraction to util/test. Includes mini_chromium roll with: 56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows 886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString R=mark@chromium.org, rsesek@chromium.org BUG=crashpad:1, crashpad:13 Review URL: https://codereview.chromium.org/1001673002
2015-03-20 15:45:54 -07:00
} // namespace
} // namespace test
} // namespace crashpad
Reference in New Issue Copy Permalink