UnixStream doesn't support abstract addresses

[jethrogb]

From RFC 1479:

Linux's abstract namespace is not supported. Functionality may be added in the future via extension traits in std::os::linux::net.

This feature is described in the Linux unix(7) manpage.

This issue tracks the absence of (and hopefully future development of) this feature.

[sfackler]

This should be pretty easy to add for anyone that's interested!

[jethrogb]

Not that easy... I'd probably want to change UnixStream::connect to take a A: Into<SocketAddr> and then impl<T: AsRef<Path>> From<T> for SocketAddr. But, that conversion is fallible (see std::sys::unix::ext::sockaddr_un). So you need TryInto. But then you can't supply a SocketAddr directly until we get impl<T, U> TryFrom<U> for T where T: From<U>, which requires !...

[sfackler]

Abstract namespaces are Linux only so we'd only want to make them available through a Linux-only method. Probably something like

pub trait UnixStreamExt {
    fn connect_abstract(name: &[u8]) -> io::Result<UnixStream>;
}

pub trait SocketAddrExt {
    fn as_abstract(&self) -> Option<&[u8]>;
}

[jethrogb]

That seems like a strange API, to have two different connect functions. You can have it be Linux only to have an extension trait to create a SockAddr on Linux only.

[sfackler]

But then you can't supply a SocketAddr directly until we get impl<T, U> TryFrom for T where T: From, which requires !...

Why is it impossible to implement TryFrom from a type to itself without !?

[retep998]

@sfackler Because we want to indicate that the TryFrom implementation will never fail, so gotta wait until ! is available.

[jethrogb]

Actually that might still not work, because now you need TryFrom<Err=io::Error> for AsRef<Path> and TryFrom<Err=!> for SocketAddr...

[sfackler]

@retep998

1. ! is not the only way to indicate that. String's FromStr impl has always been infallible: https://doc.rust-lang.org/src/collections/string.rs.html#1829-1852
2. How is that valuable in any way in practice? When have you ever said, "man, this code I'm trying to write would have been way better if some_socket_addr.to_socket_addrs() returned a Result<T, !> instead of Result<T, io::Error>"? If you're working in a concrete context you're not going to use try_from to go from a type to itself, and if you're in an generic context, you're only going use try_from if you want to deal with the failure case anyway.

[metux]

I'd advice against using that misfeature. In the past 20 years, I've never seen any practical usecase
for that, and it creates more trouble than it's actually worth it.

[jethrogb]

@metux practical use-case is interoperability with other software that creates an abstract socket?

[metux]

Ok. Does anyone here run an application which needs that ? I don't recall any in the last two decades.

[jethrogb]

Would I have opened this ticket if I didn't?