std.c should reflect the CRT, not std.posix's bizarre view of the world.
Also:
* Audit some incorrect std.c types and function signatures
* Remove ws2_32 from std.c (dubious quality, and ws2_32 isn't libc)
* Remove remnants of Windows support in std.posix
closes https://codeberg.org/ziglang/zig/issues/37382
netReadWindows and netWriteWindows returned error.Unexpected when AFD
reported STATUS_LOCAL_DISCONNECT. I was able to produce this error in
both the read and write paths locally.
Partial fix of #31956
Tested with a program that calls `stdin().stat(io)`. With this change, the following all work and return `.kind = .character_device` whereas before they would hit error.Unexpected or panic:
stdin-stat.exe
stdin-stat.exe < NUL
stdin-stat.exe < COM1
stdin-stat.exe < AUX
Without this, the child trying to read the attributes of the stdout/stderr/stdin file (NtQueryInformationFile, NtQueryVolumeInformationFile, etc) would get ACCESS_DENIED. It's not strictly necessary on the server side of the pipe but I don't see a reason not to set it there, too.
A read can fail with EACCES on a file that was opened successfully, e.g.
procfs entries such as /proc/<pid>/stack check permissions at read time.
The readv, preadv and pread switches did not handle it, so it ended up
in unexpectedErrno which dumps a stack trace in Debug builds.
The IPv6 formatter code now emits the :IPv4 alternate text form
for both "IPv4 Mapped" and "Well-Known Prefix" (RFC 6052).
The IPv6 parser now accepts the :IPv4 form regardless of what the
first 12 bytes are, so long as there is no trailing "%interface"
(which should only be useful for link-locals anyways). RFC 4291
does not require any special prefix for the :IPv4 form on the
parsing side, and there are many non-canonical cases in the real
world which should still parse correctly.
If there were multiple potential messages to receive, and some
were received successfully before encountering an error, it should
report the count of succesful receives along with the error found
during the final attempt.
Without this change, on some targets (e.g. aarch64-freebsd),
calling `cmsg.data()` with `Iterator.message.header` as the
argument would result in compilation failures like:
error: expected type '*align(8) c.posix_cmsghdr', found '*c.posix_cmsghdr'
ios, tvos, visionos and watchos can't spawn processes, so their
null_file has no fd and spawnDarwin doesn't compile for them. The
vtable always references processReplace and the default panic handler
uses Threaded, so nearly every program for these targets failed to
compile. Fall back to posixExec there, as before 9fe0ebe108.
closes https://codeberg.org/ziglang/zig/issues/37061
It is not clear to me that this is the right path to take, using a
shared buffer for control data makes managing the alignment trickier,
and would require the Io interface itself to deal with alignment.
For an example of what I consider clean design, see net_read/net_write.
There is no need for the Io interface/operations to be aware of control
buffer alignment and it is sufficient for the net.Stream.Reader
abstraction to use an aligned buffer.
Also this has no test coverage and is (to my knowledege)
not currently blocking any real world Zig project.
This reverts commit 7c0347fce0b6f510b43ca503ad9c1cd2f8ac9a6b.
Similarly to the other unix socket test, this test opens a unix socket,
but also uses the newly-introduced control data API to pass a file
descriptor to the other side.
The other side then writes to the file descriptor, then deletes the
temporary file.
Also adds a way to read control data using Stream.Reader. Stream.Reader
will buffer control data until it can't no more, in which case it will
be truncated.
The readv syscall in netReadPosix has been replaced with recvmsg.
A couple of changes to improve reception of control data when using the
datagram API.
Instead of having a separate control buffer per received message,
there's one big buffer that all messages share (like the data buffer).
This means that now IncomingMessage has no user-initialised fields, and
can be initialised with undefined (which means that .init is now
deprecated).
Also, instead of taking a pointer to mutable IncomingMessage,
netReceiveOne* functions simply return a IncomingMessage.
1. @bitCast has no target type anymore and throws error, discard it
because the old errno only accept usize. The new errno takes any
integer width and does the signed conversion itself
2. also throw away the widening (i32 -> usize), the logic is in linux.errno
now
With a test case that (1) calls createFileMap on a 250MiB text file, and (2) reads every byte in the mapped region looking for `\n`, hard page faults were eliminated in the `populate = true` case. `rammap -Et` is used to clear the relevant Windows cache.
```
> rammap -Et
> bench-no-populate.exe
.{ .page = 1090, .hard = 0 } // initial count
.{ .page = 1112, .hard = 0 } // after createFileMap
.{ .page = 1114, .hard = 0 } // after 1s sleep
4194304 newlines in the file
.{ .page = 66779, .hard = 255 }
> rammap -Et
> bench-populate.exe
.{ .page = 1093, .hard = 0 } // initial count
.{ .page = 1242, .hard = 0 } // after createFileMap
.{ .page = 1244, .hard = 0 } // after 1s sleep
4194304 newlines in the file
.{ .page = 66782, .hard = 1 }
```
More details are in https://codeberg.org/ziglang/zig/pulls/36964
This both fixes populate=false, since NtCreateSection needs COMMIT=true when called with a file handle (the higher level API sets this flag for the user), and also signals the intention to prefetch when populate=true, which wasn't happening before.
However, PrefetchVirtualMemory (and the ntdll equivalent NtSetInformationVirtualMemory with MEMORY_PREFETCH_INFORMATION) doesn't appear to actually do anything to decrease the number of page/hard faults. We still do the call though since it accurately signals intent, and future version of Windows may be able to do something with that.
Masa Bence