I'm learning something on win32 programming. I read on the reference manual (here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx ) that
If lpOverlapped is not NULL, the read operation starts at the offset that is specified in the OVERLAPPED structure and ReadFile does not return until the read operation is complete. The system updates the OVERLAPPED offset before ReadFile returns.
However if I call ReadFile(hmyFile, &myrecord, sizeof(record_t), &n, &ov); I see that the value ov.offset stay unchanged. How so? Where am I misunderstanding what is stated in the reference manual?
More details:
The file handler is opened as hmyFile = CreateFile(argv[1], GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
I'm not using FILE_FLAG_OVERLAPPED
As the comments indicate it's an error in the documentation. The actual behaviour is that file pointer is updated, just like when lpOverlapped is NULL and the handle is synchronous. Older versions of the documentation get this right. The following is taken from the July 2000 version of the Platform SDK documentation:
The ReadFile function reads data from a file, starting at the position indicated by the file pointer. After the read operation has been completed, the file pointer is adjusted by the number of bytes actually read, unless the file handle is created with the overlapped attribute. [...]
If hFile is not opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the read operation starts at the offset specified in the OVERLAPPED structure. ReadFile does not return until the read operation has been completed.