On Sat Jul 4 20:48:15 2026 +0000, Elizabeth Figura wrote:
Meh, I can't read, the rest is supposed to be handled by short write handling. That makes sense. Though it would be nice to have a test that makes sure all the data comes through. Why are we limiting this to TCP? Added receive-side verification: the test now reads everything back on the peer socket and checks both the total size and the byte content (each buffer carries a distinct byte value, so reordering or dropped tails would be caught).
Regarding limiting this to stream sockets: for SOCK_STREAM a short send is transparent — the clamped tail is resent by the short-write handling and the byte stream on the wire is unchanged. For message-oriented sockets each sendmsg() produces one datagram, so clamping the iovec count would split a single datagram into several, changing what appears on the wire. Supporting >IOV_MAX buffers for datagrams would instead require coalescing the payload into a temporary buffer, which seemed better left to a separate change if there's demand — the real-world breakage here was on stream sockets (gRPC's HTTP/2 transport batching one WSABUF per frame slice). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11316#note_144861