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/