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 http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk