...Windows doesn't do it this way, although according to the docs other members of the overlapped structure are modified by Windows.
Ok, we need to rewrite GetOverlappedResult to use the internal structures (and get the hEvent we might have created in ReadFile), instead of relying on the one from the overlapped struct itself
I'd rather say it's GetOverlappedResult which is to blame. If the hEvent is NULL, then we shouldn't return any error (as we do) but rather assume all wait operation succeed (if hEven is NULL, ReadFile and WriteFile operations are synchronous, so calling GetOverlappedResult is a no-op).
This turns out not to be the case. As long as lpOverlapped is supplied, a NULL hEvent will work fine and allows overlapped reads.
Could you also test it with opening a file (files and sockets semantics are somehow different)
Ah, I didn't know that. If we keep calling CreateEvent over and over again with a NULL parameter, will we eventually run out of some resource? If so, it may still be best to construct a name, since calling CreateEvent with the same name twice will apparently avoid creating another event.
if you run out of resource with calling with a NULL parameter, you'll also get out of resource with constructing the name, so you don't need to bother here
The attached test program uses overlapped reads with a NULL hEvent in the OVERLAPPED structure to connect to an IP address and port given on the command line. Here's an example from Windows:
C:>overlapped-test 216.12.213.139 25 Calling ReadFile ReadFile returned ERROR_IO_PENDING, as expected ov .hEvent=00000000 Calling Sleep(2000) Calling GetOverlappedResult GetOverlappedresult read 85 bytes: 220 2search2.com ESMTP Sendmail 8.10.2-SOL3/8.10.2; Mon, 17 May 2004 11:58:26 -0400
just for fun, what gives without the Sleep ? A+