https://bugs.winehq.org/show_bug.cgi?id=55952
--- Comment #26 from Zeb Figura z.figura12@gmail.com --- What is the upshot of all this? If we want to avoid reporting an error for RST after FIN, we have to specifically wait for FIN *at all times*. If we just poll as now, we don't have a way of knowing whether an RST happened after a FIN or not. [Note that Linux will return 0 on a reset socket once the error has been consumed.] This is not necessarily a problem, though.
The other upshot of all this is that, in trying to consume all the remaining data but using a 0-byte recv to do it, this test is definitely doing something broken. It works in practice, mind, but now that I've analyzed why it works, I think I can say with certainty that it works accidentally. If nothing else it's fragile, and should be fixed.
With that in mind, is it worth trying to fix this on the Wine end anyway? Maybe, but I'm not convinced. I can easily believe that a real application would do something this buggy, but on the other hand, we haven't seen one yet. And touching socket code has an astounding propensity to cause regressions, even if a great deal of them are simply because they expose other bugs. If nothing else I feel nervous about making a nontrivial change like this during code freeze.