According to MSDN ReadFile() Win32 function may incorrectly report read operation completion. When?

Posted by Martin Dobšík on Stack Overflow See other posts from Stack Overflow or by Martin Dobšík
Published on 2010-03-18T19:35:21Z Indexed on 2010/03/18 19:41 UTC
Read the original article Hit count: 468

The MSDN states in its description of ReadFile() function (http://msdn.microsoft.com/en-us/library/aa365467%28VS.85%29.aspx):

“If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must point to a valid and unique OVERLAPPED structure, otherwise the function can incorrectly report that the read operation is complete.”

I have some applications that are violating the above recommendation and I would like to know the severity of the problem. I mean the program uses named pipe that has been created with FILE_FLAG_OVERLAPPED, but it reads from it using the following call:

ReadFile(handle, &buf, n, &n_read, NULL);

That means it passes NULL as the lpOverlapped parameter. That call should not work correctly in some circumstances according to documentation. I have spent a lot of time trying to reproduce the problem, but I was unable to! I always got all data in right place at right time. I was testing only Named Pipes though.

Would anybody know when can I expect that ReadFile() will incorrectly return and report successful completion even the data are not yet in the buffer? What would have to happen in order to reproduce the problem? Does it happen with files, pipes, sockets, consoles, or other devices? Do I have to use particular version of OS? Or particular version of reading (like register the handle to I/O completion port)? Or particular synchronization of reading and writing processes/threads?

Or when would that fail? It works for me :/

Please help!

With regards

Martin

© Stack Overflow or respective owner

Related posts about win32

Related posts about overlapped-io