Signed-off-by: Jinoh Kang jinoh.kang.kr@gmail.com --- dlls/ws2_32/tests/sock.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c index 782b1e59729..966a681e809 100644 --- a/dlls/ws2_32/tests/sock.c +++ b/dlls/ws2_32/tests/sock.c @@ -11520,6 +11520,8 @@ static void test_simultaneous_async_recv(void) const void *expect = msgstr + i * stride; const void *actual = resbuf + i * stride; DWORD size; + int allcmp; + size_t j;
ret = WaitForSingleObject(events[i], 1000); ok(!ret, "wait timed out\n"); @@ -11528,6 +11530,20 @@ static void test_simultaneous_async_recv(void) ret = GetOverlappedResult((HANDLE)client, &overlappeds[i], &size, FALSE); ok(ret, "got error %u\n", GetLastError()); ok(size == stride, "got size %u\n", size); + + allcmp = 0; + for (j = 0; j <= num_io * stride - size; j++) allcmp |= !memcmp(msgstr + j, actual, size); + ok(allcmp, "returned data shall be part of original message (got %s)\n", debugstr_an(actual, size)); + + /* Observation: Windows *always* respects the order of WSARecv() calls + * and fills out the buffers in first-in-first-out manner. + * + * This behaviour is admittedly not clearly documented, and it can be + * argued that a well-designed application would instead use vectored + * I/O with an array of WSABUFs, which are then are guaranteed to be + * filled out in order. However, at least one real-world application + * is known to rely on the WSARecv() order-respecting behaviour. + */ ok(!memcmp(expect, actual, stride), "expected %s, got %s\n", debugstr_an(expect, stride), debugstr_an(actual, stride)); }