std::net::TcpStream::connect_timeout on vxworks

[biabbas]

I'm tracking a issue with connect_timeout function on rust for vxworks. The function is also accepting connections on a non responsive server port. I get errors on unreachable host, but with host that are reachable any connection to a non existent server port is not resulting in an error.

example program:

use std::{
    net::{SocketAddr, TcpStream},
    time::Duration,
};

fn main() {
    let sock_addr: SocketAddr = std::env::args()
        .into_iter()
        .nth(1)
        .unwrap()
        .parse()
        .unwrap();
    dbg!(sock_addr);
    let timeout = Duration::from_secs(5);
    let maybe_stream = TcpStream::connect_timeout(&sock_addr, timeout);
    match maybe_stream {
        Ok(_stream) => println!("Successfully connected to server"),
        Err(err) => eprintln!("Failed to connect to server: {:?}", err),
    };
}

Results:

./exe 127.0.0.1:90 /// No server at this port

Successfully connected to server

./exe 192.0.0.1:20 //// Host is unreachable so correct behaviour.

Failed to connect to server

./exe 172.16.2.223:8002 //Host is reachable, but there's no server at this port

Successfully connected to server

This is not observed with the connect function. I don't see a specified folder in library/std/src/sys/pal for vxworks. I found only one file for vxworks library/std/src/sys/pal/unix/process/process_vxworks.rs files. Does vxworks fall back on unix implementations for these functionalities? Any leads on how to proceed would be really helpful.

[workingjubilee]

@biabbas I don't mean to quibble much but tracking issues are not for "tracking" bugs, they are for tracking long-term projects that need issues-that-connect-issues.

[workingjubilee]

I don't see a specified folder in library/std/src/sys/pal for vxworks. I found only one file for vxworks library/std/src/sys/pal/unix/process/process_vxworks.rs files. Does vxworks fall back on unix implementations for these functionalities? Any leads on how to proceed would be really helpful.

Yes, see https://github.com/rust-lang/rust/pull/77666 for why: basically our support was previously a trivial copy of the Unix support. The result may be buggy, because we do not really run CI against VxWorks. We are happy to accept patches, and even happier to have maintainers who are interested in repairing the target on a regular basis.

[biabbas]

I don't see a specified folder in library/std/src/sys/pal for vxworks. I found only one file for vxworks library/std/src/sys/pal/unix/process/process_vxworks.rs files. Does vxworks fall back on unix implementations for these functionalities? Any leads on how to proceed would be really helpful.

Yes, see #77666 for why: basically our support was previously a trivial copy of the Unix support. The result may be buggy, because we do not really run CI against VxWorks. We are happy to accept patches, and even happier to have maintainers who are interested in repairing the target on a regular basis.

Thank You. I'll be continuously working on vxworks rust. So I'll be able to check this on a regular basis. Since rust 1.6 we've been maintaining a custom patch for rust build for vxworks. I'll update it for nightly and create a PR. I would like to be a code maintainer for this.

[workingjubilee]

@biabbas All you have to do to be listed as a maintainer is to add a doc using this template in rustc/src/platform-support/

https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/src/doc/rustc/src/platform-support/TEMPLATE.md