std::net: adding new option todevice.

[devnexen]

Allows to bind a socket to an network interface, to exclusively listen from it. For packet sockets, regular bind is more appropriate.

tracking issue: #129182

[rustbot]

r? @Noratrieb

rustbot has assigned @Noratrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Noratrieb]

Thank you for the PR! This PR contains a public library API change, which should follow the process of creating an ACP first: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html
Use @rustbot ready when your ACP has been accepeted.
@rustbot author

[devnexen]

Sorry for asking but is creating ACP a different process than tracking issue ?

[Noratrieb]

Yes, asking for an ACP, which is a relatively new process, asks the libs-api team whether this is worth adding in the first place. The tracking issue is there once it has been added, to track stabilization.

[biabbas]

Bytes with null will return an Interior null runtime error when device names are shorter then 16 characters.
for example eno1 would be represented as [101, 110, 111, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0].

Suggested change

	let ifrname = CStr::from_bytes_with_nul(s).unwrap();
	let ifrname = CStr::from_bytes_until_nul(s).unwrap();

[programmerjake]

this should probably check if the input name is too long rather than silently truncating it because you used zip()

[biabbas]

That value is already truncated to size specified by optlen when getsockopt is called with optlen.

[biabbas]

Plus length of interface is 16 on most unix systems, so no value is truncated.

[programmerjake]

what I mean is, assuming IFNAMSIZ == 16, if you have an interface named mylonginterface (15 bytes), and you call this function with "mylonginterfacename" then it will silently truncate that and use mylonginterface instead of erroring like it should, because setsockopt never has a chance to see the bad name and report an error.

[biabbas]

Something seems odd here.

#![feature(unix_set_todevice)]
use std::os::unix::net::UnixDatagram;
    ///
fn main() -> std::io::Result<()> {
    let socket = UnixDatagram::unbound()?;
    socket.set_todevice(c"eno1")?;
    let name = socket.todevice()?;
    assert_eq!(Ok("eno1"), name.to_str());
    Ok(())
}

The assertion fails.

thread 'main' panicked at test_case.rs:8:5:
assertion `left == right` failed
  left: Ok("eno1")
 right: Ok("�
�")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

undefined behavior is resolved

[joshtriplett]

Why is this using UnixStream? That...shouldn't work.

The examples should be things expected to work.

[joshtriplett]

Wait, it looks like these are being added to UNIX sockets? Shouldn't these be for TCP/UDP, not UNIX?

[the8472]

My understanding of the SO_BINDTODEVICE must be used before binding or connecting a socket. Currently std has no way to support this, TcpStream and TcpListener constructors create already-bound / already-connected sockets.

So to support this std would first have to gain a way to create unbound sockets, configure them and then turn them into their final type.

see rust-lang/libs-team#66 (comment)

Additionally device-binding is a platform-specific API that's not fully portable. So it'd have to go into extension traits under the os module.

So I have to reject this for now until we have a better story around unbound sockets.

For now you can use the socket2 crate, which has device-binding methods