Re: [boost] [AFIO] Formal review

Subject: Re: [boost] [AFIO] Formal review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-09-01 20:29:49

On 1 Sep 2015 at 17:34, Gavin Lambert 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.

ASIO uses the problematic parameter to pass a pointer to some state. 
The segfault is caused by ASIO dereferencing that pointer.

> 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.

It's only x86 on x64 kernels, but that is still a common enough case. 
I do agree, and it'll be fixed in the refactor removing ASIO.

> > 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.
> 
> 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.)

I have been thinking about this, and I do see how it would be 
unhelpful if a shipping product saw a bit flip from a cosmic ray and 
AFIO hoses the process. It would get in the way of telemetry.

I may consider instead to flip a global boolean which permanently 
stops dead and disables AFIO in that process. That would prevent the 
damage of other people's data, but still allow you to send telemetry.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/