Currenty copy_file_range always uses at least two syscalls:
1. As many as it needs to do the initial copy (always 1 during my
testing)
2. The last one is always when offset is the size of the file.
The second syscall is used to detect the terminating condition. However,
because we do a stat for other reasons, we know the size of the file,
and we can skip the syscall.
Sparse files: since copy_file_range expands holes of sparse files, I
conclude that this layer was not intended to work with sparse files. In
other words, this commit does not make it worse for sparse file society.
Test program
------------
const std = @import("std");
pub fn main() !void {
const arg1 = std.mem.span(std.os.argv[1]);
const arg2 = std.mem.span(std.os.argv[2]);
try std.fs.cwd().copyFile(arg1, std.fs.cwd(), arg2, .{});
}
Test output (current master)
----------------------------
Observe two `copy_file_range` syscalls: one with 209 bytes, one with
zero:
$ zig build-exe cp.zig
$ strace ./cp ./cp.zig ./cp2.zig |& grep copy_file_range
copy_file_range(3, [0], 5, [0], 4294967295, 0) = 209
copy_file_range(3, [209], 5, [209], 4294967295, 0) = 0
$
Test output (this diff)
-----------------------
Observe a single `copy_file_range` syscall with 209 bytes:
$ /code/zig/build/zig build-exe cp.zig
$ strace ./cp ./cp.zig ./cp2.zig |& grep copy_file_range
copy_file_range(3, [0], 5, [0], 4294967295, 0) = 209
$
When creating an `EmulatableRunStep`, it now correctly depends
on its own step rather than only the executable that was created.
This means we do not need to add extra `dependOn` statements on
both the emulatable step as well as the check object step.
same change as [68e26a2cee] "std: check for overflow in writeCurrentStackTrace"
On arm64 macOS, the address of the last frame is 0x0 rather than
a positive value like 0x1 on x86_64 macOS, therefore, we overflow
an integer trying to subtract 1 when printing the stack trace. This
patch fixes it by first checking for this condition before trying
to subtract 1.
Same behaviour on i386-windows-msvc.
Note that we do not need to signal the `SignalIterator` about this
as it will correctly detect this condition on the subsequent iteration
and return `null`, thus terminating the loop.
* Sema: implement linksection on functions
* Implement function linksection in Sema.
* Don't clobber function linksection/align/addrspace in Sema.
* Fix copy-paste typo in tests.
* Add a bunch of missing test_step.dependOn.
* Fix checkInSymtab match.
Closes#12546
* Fix for: DefaultRwLock accumulates write-waiters, eventually fails to write lock #13163
* Comment out debug.print at the end of the last test.
* Code formatting
* - use equality test after lock/unlock rather than peeking into internals.
however, this is still implementation specific and only done for
DefaultRwLock.
- add num_reads maximum to ensure that reader threads stop if writer threads are
starved
- use relaxed orderings for the read atomic counter
- don't check at the end for non-zero read ops, since the reader threads may
only run once if they are starved
* More review changes
- Monotonic is sufficient for incrementing the reads counter
- For ALU operations, src should be allowed to be an explicit Reg.
- Expose AluOp and JmpOp as public types.
This makes code generation using BPF as a backend easier,
as AluOp and JmpOp can be used directly as part of an IR
Due to the unavailability of fchdir in Windows, a call for setting the
CWD needs to either call chdir with the path string or call
SetCurrentDirectory.
Either way, since we are dealing with a Handle in Windows, a call for
GetFinalPathNameByHandle is necessary for getting the file path first.
The definition of HKEY__ as a struct with an unused int field is only the case in the Windows headers when `STRICT` is defined. From https://learn.microsoft.com/en-us/windows/win32/winprog/enabling-strict:
> When STRICT is defined, data type definitions change as follows:
>
> - Specific handle types are defined to be mutually exclusive; for example, you will not be able to pass an HWND where an HDC type argument is required. Without STRICT, all handles are defined as HANDLE, so the compiler does not prevent you from using one type of handle where another type is expected.
Zig's `opaque {}` already gives this benefit to us, so the usage of a struct with an unused field is unnecessary, and it was causing HKEY to have an alignment of 4, which is a problem because there are HKEY constants like HKEY_LOCAL_MACHINE (0x80000002) that are not 4-byte aligned. Without this change, the compiler would not allow something like HKEY_LOCAL_MACHINE to be defined since it enforces pointer alignment.
This makes the following changes for i386:
long long and unsigned long long have 4 byte alignment on non-Windows
f64 (double) has 4-byte alignment on non-Windows
long double is 80 bits and has 4 byte alignment on mingw
long double on android is 64 bits, not 80: https://www.uclibc.org/docs/psABI-i386.pdfFixes#12453Fixes#12987
I think this may be helpful in the future when we might want to calculate this again at some other point.
It also makes it more clear that the other two functions below it are only required for this calculation.
* prep: output_buffer -> output_buffer_slice
* fix: truncate lines accurately
Currently, the code assumes a terminal width of 100.
If we look at what's printed for the last test:
```
Test [1/1] test "basic functionality"... [101/100] this is a really long name designed to activate the truncation code. let's fi...
```
No, it does not really work because the relevant part here is `"[101/100] this is a really long name designed to activate the truncation code. let's fi... "`,
which is 90 characters, but we expect 100 because that's the width that is assumed.
The reason is that it also measures **unprintable characters** (escape sequences) at least non-Windows systems.
With this commit the output is now:
```
Test [1/1] test "basic functionality"... [101/100] this is a really long name designed to activate the truncation code. let's find out if...
```
Of which `"[101/100] this is a really long name designed to activate the truncation code. let's find out if... "`
is the actual output of *our* `std.Progress` (remember that `zig test` has an `std.Progress` and our test itself does).
The length of that string is 100. Now the length is consistent with Windows where we don't use escape sequences. This issue was only present on non-Windows systems.
* feat: decide optimal maximum width
This is done by 1. getting the current terminal width and 2. subtracting that by the current cursor column. This accounts for previous output from someone else.
* test: add more tests
They make it easier to see how the progress line is printed in different cases.
* style: fix typo and improve docs
It also expands an acronym used as a variable name. It confused me.
* cleanup: import std.time
* test: add test
* fix: limit termios usage to Linux only for now
* fix: missing cast on Windows
* test: try to debug failure
* fix: fix off-by-one and disable tests
* docs: make comment clearer
* fix: more durability
* fix(getTerminalWidth): change order
Previously, you might obtain `-lLLVM-15` from the CMake configuration,
but we might not be able to locate the library if it's not in your
system library path.
build.zig:
- use "-I" instead of "-isystem" for `b.addSearchPrefix()`
main.zig:
- silently ignore superfluous search dirs
- warn when a dir is added to multiple searchlists
- consolidate "expected paramter after {s}" fatal error messages
- rename command-line switch `-dirafter` → `-idirafter`
closes#12888
