| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
| |
Reviewed-by: Trust Me
(cherry picked from commit ac5c099cc3c5b8c7eec7a49fdeb8a21037230350)
|
| |
|
|
|
|
|
|
|
|
| |
On this platform mmap'ing beyond EOF may succeed, even beyond filesystem
capabilities, but generate Bus Errors on access.
Skipping this failing test and accepting the underlying undefined
behavior is the right thing to do, until QFile offers proper guarantees.
Reviewed-by: Thiago Macieira
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: thartman
|
| |
|
|
|
|
|
|
|
|
|
| |
Saw a couple of sporadic failures on Windows platforms. Debug output
should help find what's happening.
Once the fillFileSparsely test fails, there's no point in trying to read
what we failed to write so maximum tested size is reset on a failed
write.
Reviewed-by: Markus Goetz
|
| |
|
|
|
| |
... so we test the file engine directly and detect file-system errors
earlier.
|
| |
|
|
|
|
|
|
|
| |
Not when linking dynamically to the CRT (/MT). So we can't rely on them.
The declarations for those are also not on the standard headers.
Reverts "(MSVC 2002/2003) Use 64-bit versions of ftell and fseek", fixes
return type of QT_FTELL and skips known failures on large-file test
case.
|
| |
|
|
|
|
| |
The test assumed fileName was stable, but it is documented behaviour
that this can be reset when a file descriptor or FILE* stream is
associated with a QFile. This was the case on Windows.
|
|
|
The test case creates a (tentatively sparse) very large file with
scattered data and uses it to test various aspects of large file support
in QFile.
Reviewed-by: Thiago Macieira
|
