A `NULL` from `readdir` could be the end of stream or an error. The
only way to know is to check `errno`, so it must be set to a known value
first, like a 0 that POSIX will never use.
This patch adds `set_errno`, uses it to clear the value before calling
`readdir`, then checks it again after to see the reason for a `NULL`.
The `use ffi::CStr` in `unix/thread.rs` was previously guarded, but now
all platforms need it for `Thread::set_name()`. Newlib and Solaris do
nothing here, as they have no way to set a thread name, but they still
define the same method signature.
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.
Josh Stone