In #108326, `read_buf` was implemented for a variety of types, but SGX
was saved for later. Update a test from then, now that #137355
implemented it for SGX types.
Having these implementation available crate-wide means that platforms not using sockets for their networking code have to stub out the libc definitions required to support them. This PR moves the conversions to private helper functions that are only available where actually needed.
I also fixed the signature of the function converting from a C socket address to a Rust one: taking a reference to a `sockaddr_storage` resulted in unsound usage inside `LookupHost::next`, which could create a reference to a structure smaller than `sockaddr_storage`. Thus I've replaced the argument type with a pointer and made the function `unsafe`.
This was never modified since `std::net` was originally introduced, when
each CI job was running multiple jobs concurrently which caused issues
with fighting over the same ports. This is not the case in the current
CI infrastructure, so remove this relic.
As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.
I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
Hook up std::net to wasi-libc on wasm32-wasip2 target
One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.
There are currently a few limitations:
- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)
Do those decisions make sense?
While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?
cc `@alexcrichton`
Clarifications for set_nonblocking methods
Closes#129903.
The issue mentions that `send`, `recv` and other operations are interpreted by some users as methods of `TcpSocket` which led to confusion since it hasn't them. To fix it I added "system" into the documentation as being more precise for two reasons:
* it's makes it clear that these names are system operations;
* it doesn't point to the location of these methods like `libc` because not every system is POSIX compatible.
This is possible now that inline const blocks are stable; the idea was
even mentioned as an alternative when `uninit_array()` was added:
<https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>
> if it’s stabilized soon enough maybe it’s not worth having a
> standard library method that will be replaceable with
> `let buffer = [MaybeUninit::<T>::uninit(); $N];`
Const array repetition and inline const blocks are now stable (in the
next release), so that circumstance has come to pass, and we no longer
have reason to want `uninit_array()` other than convenience. Therefore,
let’s evaluate the inconvenience by not using `uninit_array()` in
the standard library, before potentially deleting it entirely.
detects redundant imports that can be eliminated.
for #117772 :
In order to facilitate review and modification, split the checking code and
removing redundant imports code into two PR.
Improve UdpSocket documentation
I tried working with `UdpSocket` and ran into `EINVAL` errors with no clear indication of what causes the error. Also, it was uncharacteristically hard to figure this module out, compared to other Rust `std` modules.
1. `send` and `send_to` return a `usize` This one is just clarity. Usually, returned `usize`s indicate that the buffer might have only been sent partially. This is not the case with UDP. Since that `usize` must always be `buffer.len()`, I have documented that.
2. `bind` limits `connect` and `send_to` When you bind to a limited address space like localhost, you can only `connect` to addresses in that same address space. Error kind: `AddrNotAvailable`.
3. `connect`ing to localhost locks you to localhost On Linux, if you first `connect` to localhost, subsequent `connect`s to
non-localhost addresses fail. Error kind: `InvalidInput`.
For debugging the third one, it was really hard to find someone else who already had that problem. I only managed to find this thread: https://www.mail-archive.com/netdev@vger.kernel.org/msg159519.html
I tried working with `UdpSocket` and ran into `EINVAL` errors with no
clear indication of what causes the error. Also, it was uncharacteristically
hard to figure this module out, compared to other Rust `std` modules.
1. `send` and `send_to` return a `usize`
This one is just clarity. Usually, returned `usize`s indicate that the
buffer might have only been sent partially. This is not the case with
UDP. Since that `usize` must always be `buffer.len()`, I have documented
that.
2. `bind` limits `connect` and `send_to`
When you bind to a limited address space like localhost, you can only
`connect` to addresses in that same address space. Error kind:
`AddrNotAvailable`.
3. `connect`ing to localhost locks you to localhost
On Linux, if you first `connect` to localhost, subsequent `connect`s to
non-localhost addresses fail. Error kind: `InvalidInput`.
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Implement read_buf for TcpStream, Stdin, StdinLock, ChildStdout,
ChildStderr (and internally for AnonPipe, Handle, Socket), so
that it skips buffer initialization.
The other provided methods like read_to_string and read_to_end are
implemented in terms of read_buf and so benefit from the optimization
as well.
This commit also implements read_vectored and is_read_vectored where
applicable.
Add support for QNX Neutrino to standard library
This change:
- adds standard library support for QNX Neutrino (7.1).
- upgrades `libc` to version `0.2.139` which supports QNX Neutrino
`@gh-tr`
⚠️ Backtraces on QNX require https://github.com/rust-lang/backtrace-rs/pull/507 which is not yet merged! (But everything else works without these changes) ⚠️
Tested mainly with a x86_64 virtual machine (see qnx-nto.md) and partially with an aarch64 hardware (some tests fail due to constrained resources).
`IN6ADDR_ANY_INIT` and `IN6ADDR_LOOPBACK_INIT` documentation.
Added documentation for IPv6 Addresses `IN6ADDR_ANY_INIT` also known as `in6addr_any` and `IN6ADDR_LOOPBACK_INIT` also known as `in6addr_loopback` similar to `INADDR_ANY` for IPv4 Addresses.
Added documentation for IPv6 Addresses `IN6ADDR_ANY_INIT` also known as
`in6addr_any` and `IN6ADDR_LOOPBACK_INIT` also known as
`in6addr_loopback` similar to `INADDR_ANY` for IPv4 Addresses.
