r? @joboet

rustbot has assigned @joboet.
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

r? @ChrisDenton

I'm not convinced we should handle this if the platform doesn't – depending on the platform, recv(&mut []) might be useful to detect any errors with the socket setup. But I'm no networking expert...

I'm not convinced we should handle this if the platform doesn't – depending on the platform, recv(&mut []) might be useful to detect any errors with the socket setup. But I'm no networking expert...

In windows operating system two functions of this test cases passing (just polling) but in the libc recv_from with params not giving to do this (this is windows's fault)

https://man7.org/linux/man-pages/man2/recv.2.html#top_of_page
See the RETURN VALUES header

That is C's mess of results it can return 0 if client closed connection or zero buffer given
I closed part when zero buffer given only, to make return values understandable

Or we can just close the issue, because this issue excisting a long time ago and no one answered

I think we have two options

I think this is more a question for libs-api, especially since it affects the behaviour of a currently stable API. It would probably be useful to have a decision on #55794 too if we're changing the API here but not essential. I've marked both issues (#149392 and #55794) as waiting on libs-api.

I think this is more a question for libs-api, especially since it affects the behaviour of a currently stable API. It would probably be useful to have a decision on #55794 too if we're changing the API here but not essential. I've marked both issues (#149392 and #55794) as waiting on libs-api.

I think this is more a question for libs-api, especially since it affects the behaviour of a currently stable API. It would probably be useful to have a decision on #55794 too if we're changing the API here but not essential. I've marked both issues (#149392 and #55794) as waiting on libs-api.

Thank you for your response.

For the second issue in parentheses, I have already briefly explained above the difference in behavior between POSIX and NT operating systems. My goal was simply to minimize this difference.
Thank you for mentioning. I saw the message that a discussion was needed, but I didn't quite understand. Do I need to discuss this somewhere else this? (because anyway this PR with libs api label)

libs-api meets weekly to discuss issues. No action on your part is necessary but any relevant information you can provide is useful. Summarising existing information can also be useful if the information is spread out.

These issues were discussed at the tail end of the last meeting so no definite conclusion was reached. But the general feeling seemed to be that we shouldn't be changing system behaviour here, instead we should document it. But that's just my impression, no conclusion was reached within the meeting time.

libs-api meets weekly to discuss issues. No action on your part is necessary but any relevant information you can provide is useful. Summarising existing information can also be useful if the information is spread out.

These issues were discussed at the tail end of the last meeting so no definite conclusion was reached. But the general feeling seemed to be that we shouldn't be changing system behaviour here, instead we should document it. But that's just my impression, no conclusion was reached within the meeting time.

Understand, however i think that is one of the rust's ideology, where software should have same behaviour everywhere. If another issues likes this (posix, nt, other) appears, i will try to close each one to obey this rules. But anyway about Rust's ideology you better know than me, i hope at the next weekend it will be finally resolved