Boost logo

Boost :

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 !


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk