Re: [boost] [AFIO] Formal review

Subject: Re: [boost] [AFIO] Formal review
From: Roland Bock (rbock_at_[hidden])
Date: 2015-09-01 02:57:23

On 2015-09-01 07:34, Gavin Lambert wrote:
> On 1/09/2015 04:18, Niall Douglas wrote:
>>> - The documentation notes: "Don't do directory enumerations from an
>>> x86 binary
>>>    on a x64 Windows system. This is due to a bug in Microsoft's
>>> WOW64 syscall
>>>    translation layer which Microsoft have decided is wontfix. " 
>>> Given that a
>>>    major purpose of AFIO is to provide a portable abstraction that
>>> works around
>>>    OS limitations, AFIO needs to support directory enumeration even
>>> in this case
>>>    (e.g. by detecting WOW64 and using a synchronous call via a
>>> threadpool in that
>>>    case).
>>
>> This problem is caused by how ASIO's reactor works and is due to code
>> I can't modify in ASIO. It'll go away when I rewrite ASIO's reactor
>> using lightweight futures because I can control the source code.
>
> The suggestion was that you explicitly detect the problem case (ie.
> running under WOW64) and then execute an alternate enumeration
> codepath in that case (avoid the problem API and call a different one,
> perhaps synchronously).  I'm not sure how ASIO's reactor bears any
> relationship to this.
>
> If the problem is that you need to call a synchronous API, then note
> that you can queue up work via the common threadpool reactor that
> actually executes synchronously on a dedicated worker thread, or pool
> thereof (ASIO even does this itself internally for some things, where
> async APIs are not available).  It's a little less efficient, of
> course, but not particularly difficult.
>
> If it's not about synchrony, then presumably you need to call the
> Win32 API instead of the Native API in this case.  So do that.
>
> It's not acceptable to simply say "directory enumeration doesn't work
> in 32-bit Windows processes sometimes".  That's a bug, and even if MS
> agreed to fix it you would still have to have code that worked around
> it on versions before the fix.
>
>> AFIO fatal exits the process if you try to read or write past the
>> current file size, it's a logic error and your program is inherently
>> broken.
>
> FWIW, any library choosing to fatal exit the process for ANY reason
> causes me to fatally exit the library (ie. not use it), particularly
> if it doesn't provide interception hooks.
+ 1

And even more so in this particular case since reading past the end of a
file is a recoverable error (it's not like we're deep in UB-land).

@Niall:
Compare this to vector::at(). Assume for a second a standard in some
other universe which said:

/std::vector::at() fatal exits the process if you try to read or write
past the current vector size, it's a logic error and your program is
inherently broken./

Would you want that?

If no:
Why would you want to terminate in case of reading past the end of a file?

>
> My apps have their own methods for reacting to fatal errors of any
> kind (mostly unified logging and graceful exit) and I don't appreciate
> anything that tries to bypass them.  (In fact I have some code
> specifically dedicated to preventing the VC++ CRT from trying to
> bypass the error handler.)