* Link to `process::Command` from `process::Child`.
* Move out inline Markdown link in doc comment.
* Link to `process::Child::wait` from `process::Child`.
* Link to `process::Child` from `process::ChildStdin`.
* Link to `process::Child` from `process::ChildStdout`.
* Link to `process::Child` from `process::ChildStderr`.
Use hints with getaddrinfo() in std::net::lookup_host()
As noted in #24250, `std::net::lookup_host()` repeats each IPv[46] address in the result set. The number of repetitions is OS-dependent; e.g., Linux and FreeBSD give three copies, OpenBSD gives two. Filtering the duplicates can be done by the user if `lookup_host()` is used explicitly, but not with functions like `TcpStream::connect()`. What happens with the latter is that any unsuccessful connection attempt will be repeated as many times as there are duplicates of the address.
The program:
```rust
use std::net::TcpStream;
fn main() {
let _stream = TcpStream::connect("localhost:4444").unwrap();
}
```
results in the following capture:
[capture-before.txt](https://github.com/rust-lang/rust/files/352004/capture-before.txt)
assuming that "localhost" resolves both to ::1 and 127.0.0.1, and that the listening program opens just an IPv4 socket (e.g., `nc -l 127.0.0.1 4444`.) The reason for this behavior is explained in [this comment](https://github.com/rust-lang/rust/issues/24250#issuecomment-92240152): `getaddrinfo()` is not constrained.
Various OSS projects (I checked out Postfix, OpenLDAP, Apache HTTPD and BIND) which use `getaddrinfo()` generally constrain the result set by using a non-NULL `hints` parameter and setting at least `ai_socktype` to `SOCK_STREAM`. `SOCK_DGRAM` would also work. Other parameters are unnecessary for pure name resolution.
The patch in this PR initializes a `hints` struct and passes it to `getaddrinfo()`, which eliminates the duplicates. The same test program as above with this change produces:
[capture-after.txt](https://github.com/rust-lang/rust/files/352042/capture-after.txt)
All `libstd` tests pass with this patch.
Use hints with getaddrinfo() in std::net::lookup_host()
As noted in #24250, `std::net::lookup_host()` repeats each IPv[46] address in the result set. The number of repetitions is OS-dependent; e.g., Linux and FreeBSD give three copies, OpenBSD gives two. Filtering the duplicates can be done by the user if `lookup_host()` is used explicitly, but not with functions like `TcpStream::connect()`. What happens with the latter is that any unsuccessful connection attempt will be repeated as many times as there are duplicates of the address.
The program:
```rust
use std::net::TcpStream;
fn main() {
let _stream = TcpStream::connect("localhost:4444").unwrap();
}
```
results in the following capture:
[capture-before.txt](https://github.com/rust-lang/rust/files/352004/capture-before.txt)
assuming that "localhost" resolves both to ::1 and 127.0.0.1, and that the listening program opens just an IPv4 socket (e.g., `nc -l 127.0.0.1 4444`.) The reason for this behavior is explained in [this comment](https://github.com/rust-lang/rust/issues/24250#issuecomment-92240152): `getaddrinfo()` is not constrained.
Various OSS projects (I checked out Postfix, OpenLDAP, Apache HTTPD and BIND) which use `getaddrinfo()` generally constrain the result set by using a non-NULL `hints` parameter and setting at least `ai_socktype` to `SOCK_STREAM`. `SOCK_DGRAM` would also work. Other parameters are unnecessary for pure name resolution.
The patch in this PR initializes a `hints` struct and passes it to `getaddrinfo()`, which eliminates the duplicates. The same test program as above with this change produces:
[capture-after.txt](https://github.com/rust-lang/rust/files/352042/capture-after.txt)
All `libstd` tests pass with this patch.
When resolving a hostname, pass a hints struct where ai_socktype is
set to SOCK_STREAM in order to eliminate repeated results for each
protocol family.
Issue #34076: Removing reference to removed path.prefix() function
In the documentation for `std::path::Path`, there is a [reference](https://doc.rust-lang.org/std/path/struct.Path.html#method.is_absolute) to the `path.prefix()` function which has since been removed. The offending reference is now also removed.
First pull request, feedback welcome!
r? @steveklabnik
std: Stabilize APIs for the 1.11.0 release
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
libstd stabilizations
* `Iterator::sum`
* `Iterator::product`
Deprecated
* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`
Added APIs (all unstable)
* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero
Removed APIs
* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
unstable
Closes#27739Closes#27752Closes#32526Closes#33444Closes#34152
cc #34529 (new tracking issue)
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
libstd stabilizations
* `Iterator::sum`
* `Iterator::product`
Deprecated
* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`
Added APIs (all unstable)
* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero
Removed APIs
* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
unstable
Closes#27739Closes#27752Closes#32526Closes#33444Closes#34152
cc #34529 (new tracking issue)
remove unneeded allow flag
There isn't anything deprecated being used in this function.
This built fine for me locally, but just to be sure, should check Travis.
Ignore unknown address types when looking up hosts
Previously, any function using a `ToSocketAddrs` input would fail if
passed a hostname that resolves to an address type different from the
ones recognized by Rust.
This also changes the `LookupHost` iterator to only include the known
address types, as a result, it doesn't have to return `Result`s any
more, which are likely misinterpreted as failed name lookups.
Previously, any function using a `ToSocketAddrs` input would fail if
passed a hostname that resolves to an address type different from the
ones recognized by Rust.
This also changes the `LookupHost` iterator to only include the known
address types, as a result, it doesn't have to return `Result`s any
more, which are likely misinterpreted as failed name lookups.
