Change:
// s has been moved into the tsa call } <del> // FIXME: figure out why this fails on openbsd and fix it </del> #[test] <del> #[cfg(not(any(windows, target_os = "openbsd")))] fn to_socket_addr_str_bad() { assert!(tsa("1200::AB00:1234::2552:7777:1313:34300").is_err()); </del> <ins> fn bind_udp_socket_bad() { // rust-lang/rust#53957: This is a regression test for a parsing problem // discovered as part of issue rust-lang/rust#23076, where we were // incorrectly parsing invalid input and then that would result in a // successful `UdpSocket` binding when we would expect failure. // // At one time, this test was written as a call to `tsa` with // INPUT_23076. However, that structure yields an unreliable test, // because it ends up passing junk input to the DNS server, and some DNS // servers will respond with `Ok` to such input, with the ip address of // the DNS server itself. // // This form of the test is more robust: even when the DNS server // returns its own address, it is still an error to bind a UDP socket to // a non-local address, and so we still get an error here in that case. const INPUT_23076: &'static str = "1200::AB00:1234::2552:7777:1313:34300"; assert!(crate::net::UdpSocket::bind(INPUT_23076).is_err()) </ins> } #[test]

Discussion:
This is the test from rust source repository. It says, the test fails on openbsd and bitrig, but it also fails on macOS. I guess the reason is this: is an IP address of DNS of my ISP. So for some reason, macOS decides to resolve string using DNS, and on certain ISP this resolution success. I think rust should either: disable this test on macOS as well or explicitly check if hostname contains a colon, immediately fail without passing the string to libc resolver
CC
I switched ISPs recently and I am now observing this problem on my local MacOS development box. Needless to say, it is annoying. I want to try to reconstruct the history of how we even got here. At some point, this test was as part of PR , which replaced a call deep in the guts of some addr parsing logic with in order to close issue , with the claim that this would stop us from breaking the address into more than two parts. Its possible that this test was broken even at this early date on all platforms of interest. At a later date, PR changed the meaning of the parameter to and , so that denoted the maximum number of items returned, rather than the maximum number of splits made. At that time, all of the relevant calls got changed back, so that they again pass instead of as the actual argument. The test did not need changing, since the test was written at a higher level than calls to . (I mention this event mostly so as a reminder when traversing the history that the calls that pass from this point onward are not bugs.) At a much later date, PR included a commit that heavily refactored the relevant code here, so that the calls in question moved around. But I do not think the identifiable commit () changed the semantics of the test itself.
Perhaps most importantly, the conversion in question does not return as far back as Rust 1.2.0 for me ( for some reason does not let me download versions 1.0.0 nor 1.1.0). I suspect this continues to be the same ISP dependent behavior. Here is the code I was using to observe the behavior:
The next question I have is: Why isn't this invalid input causing an error prior to the attempt to do a DNS resolve?

Interestingly, the original test case filed in issue does seem to behave as expected on my MacOS machine: an attempt to evaluate returns So even though the DNS resolve call "succeeds" by returning the IP address of the DNS server, something further along in the system still ensures that the attempt to bind a to the ill-formed address will still fail. I take this to mean that we may have another choice to make with respect to the failing test here: Perhaps we should replace the existing test that has flaky behavior with a new test that better matches the original problem.
Some context: my provider had a "feature": it resolved any DNS name to its own name, so opening a website with misspelt name opens a page with lots of ads. See the output above: it was the DNS server who successfully resolved the name , not the macOS. A user cannot bind a socket to a non-local address if I got your comment correctly, that's expected behavior.
Yes, thank you for . I think the choices in front of us are roughly as you stated in the : either: we should disable the test (on MacOS alone, or on all targets), potentially coupled with adding a different regression test, or we should change the library function to test that the input contains before passing it up to the DNS server. What we should not* do is continue to let this test flummox developers in a manner dependent on what DNS resolution service they happen to be using.