Re: [boost] [iostreams]mapped_file bug on Win32?

Subject: Re: [boost] [iostreams]mapped_file bug on Win32?
From: eg (egoots_at_[hidden])
Date: 2010-02-22 16:12:11

On 2/22/2010 11:04 AM, Nelson, Erik - 2 wrote:
> eg wrote:
>
>> However, I am just a little worried about the statement in the docs
> which say
>> "If an error has occurred, the return value of SetFilePointer is
>> INVALID_SET_FILE_POINTER and GetLastError returns a value other than
> NO_ERROR."
>
>> Perhaps this is just a case of fuzzy documentation, or I am reading too
> much
>> into the "...and GetLastError returns a value other than NO_ERROR".
>
> Not sure if you're reading too much into it, but this bug is currently
> triggered by GetLastError() returning an error when in fact no error has
> occurred.
>
> The INVALID_SET_FILE_POINTER is the more conservative test, it seems to
> me, and if SetFilePointer returns it, there *must* have been an error,
> no?
>

Ah... I see it now, the documentation describes the reason you need to 
check both:

"Note  Because INVALID_SET_FILE_POINTER is a valid value for the 
low-order DWORD of the new file pointer, you must check both the return 
value of the function and the error code returned by GetLastError to 
determine whether or not an error has occurred. If an error has 
occurred, the return value of SetFilePointer is INVALID_SET_FILE_POINTER 
and GetLastError returns a value other than NO_ERROR. For a code example 
that demonstrates how to check for failure, see the Remarks section in 
this topic."

We need to rule out the false negative case.
Wow... what a nasty API !