Boost logo

Boost :

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at