-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lack of documentation on the issue that using std::io::Write::write_all with a std::net::TcpStream results in undefined behavior when non_blocking(true) #115451
Comments
It would help to have more details here. When you say "undefined behavior" are you meaning a Rust memory safety issue? Or inconsistent or unexpected behaviour? Can you show some code that gives an example? |
original post on user forum with a solution - https://users.rust-lang.org/t/sending-data-over-a-non-blocking-socket-corrupts-data/99240 Steps to replicate - https://hackmd.io/@UiZWksNWRxCyfvxz5cAG5w/ryM0iOJR3 |
I don't think there's any UB in the standard library itself. There are a number of issues with the code, that helpful people on the user's forum have pointed out, but not with the standard library itself. There might be a documentation issue here with using |
The steps to replicate contain the following as part of let mut buf: [u8; MAX_MESSAGE_SIZE] = unsafe { MaybeUninit::uninit().assume_init() }; That's 100% insta-UB, as the warning says in https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f15d743f0a7edd56eb2aca384838643e:
So I'm going to close this as not a Feel free to re-open with a minimal repro that doesn't contain UB. (It's possible this appeared to work in past rust, but that when #111999 changed how we emit code for byte arrays it allowed LLVM to take advantage of the UB.) |
Sorry for some reason I don't see the re-open button for this issue. I am hoping you can reopen if you find below sufficient. Here is the most basic block of code that will cause "UB" I don't want to split hair on what "UB" means but in my case it just means you don't get what you expect, hence you get something that Is not clearly defined. let mut stream = TcpStream::connect(add).unwrap();
stream.nonblocking(true).unwrap()
let buf = [1,2,3,4,5];
stream.write_all(&buf[..]); // THIS LINE WILL sometime propagate a WouldBlock error kind however it would have written X number of bytes to the steam with out a way too tell if X is =0 or X<buf.len() |
changing this to SAFE init does not eliminate the issue of write_all not writing_all when the socket is notblocking, i am not sure exactly why it is unsafe to write to an uninitiated slice since the write from the socket will initialize it. I am just not aware of how else it can be done without the cost penalty, particularly since the read_buf(BorrowedCursor) 'suite' is still not stable. |
Location
lack of documentation on the issue that using std::io::Write::write_all with a std::net::TcpStream results in undefined behavior when non_blocking(true)
Summary
lack of documentation on the issue that using std::io::Write::write_all with a std::net::TcpStream results in undefined behavior when non_blocking(true)
The text was updated successfully, but these errors were encountered: