1 Sep
2015
1 Sep
'15
6:57 a.m.
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.)