UnixStream::connect regression after mio v1 upgrade

[littledivy]

UnixStream::connect with abstract address returns an Err starting from mio 1.0.0.

called `Result::unwrap()` on an `Err` value: Error { kind: InvalidInput, message: "paths must not contain interior null bytes" }

// tokio 1.39.2

use tokio::net::UnixStream;

#[tokio::main]
async fn main() {
  UnixStream::connect("\0aaa").await.unwrap();
}

Reproduction with mio:

// mio = { version = "=1.0.0", features = ["net"] } // error
// mio = { version = "=0.8.11", features = ["net", "os-poll"] } // works

use mio::net::UnixStream;

fn main() {
  UnixStream::connect("\0aaa").unwrap();
}

Expected behavior: it connects

[cailloumajor]

I have the same issue with tokio::net::UnixListener::bind. The standard library has std::os::unix::net::UnixStream::connect_addr and std::os::unix::net::UnixListener::bind_addr to allow using an abstract socket name via std::os::unix::net::SocketAddr::from_abstract_name.

[mox692]

Yes, we should probably align with mio's change.

[Darksonn]

Damn, I even looked into this and concluded that we didn't need to do anything. I guess I was wrong.

I'm not convinced we can get rid of our SocketAddr type without it being breaking.

[mox692]

Can we fallback to std's from_abstract_name if the beginning of the path is \0? (maybe it's not a very smart way though)

let addr = if path.as_ref().starts_with(b"\0") {
	StdSocketAddr::from_abstract_name(path.as_ref().as_bytes()).unwrap()
} else {
	StdSocketAddr::from_pathname(path).unwrap()
};
let stream = mio::net::UnixStream::connect_addr(&addr)?;

In the longer term, we may want to depricate our own SocketAddr.

[Darksonn]

Let's do that.

[mox692]

This was resolved in #6772 and shipped as v1.39.3