[filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
Filesystem V3 does a great job of handling unicode/utf8 paths in a windows/posix independent manner. boost::interprocess::file_mapping's constructor takes a raw const char* and explicitly calls CreateFileA to get a handle to a memory mapped file disallowing access to paths with non-ascii characters. boost::iostreams::mapped_file has a 7 month old ticket #4485 outlining the problems using it with filesystem V3. There is some path width switching logic that dispatches to CreateFileA or CreateFileW when the mapped_file is constructed with a filesystem V2 wpath. I tried faking things out by creating a wpath class in the filesystem namespace, but gave up and created a mapped file class for windows that uses filesystem::path and CreateFileW. I posted the issue with interprocess and Ion was of the opinion that this shorcoming needs to be addressed. I'm not sure if Steven is maintaining iostreams, or if he has given thought to how to address the iostreams implementation. My opinion is that boost libraries using paths in their interfaces should be using filesystem v3 paths. Beman, I think, suggested in the recent utf8 thread that boost libraries should use the wide version of the windows api passing path.wstring().c_str() where appropriate. Do others have thoughts on this issue? Are the windows wide api usage part of boost guidelines? Should they be? Thanks, Jeff
On Sat, Feb 26, 2011 at 1:31 AM, Jeff Flinn <TriumphSprint2000@hotmail.com>wrote:
Filesystem V3 does a great job of handling unicode/utf8 paths in a windows/posix independent manner.
boost::interprocess::file_mapping's constructor takes a raw const char* and explicitly calls CreateFileA to get a handle to a memory mapped file disallowing access to paths with non-ascii characters.
boost::iostreams::mapped_file has a 7 month old ticket #4485 outlining the problems using it with filesystem V3. There is some path width switching logic that dispatches to CreateFileA or CreateFileW when the mapped_file is constructed with a filesystem V2 wpath. I tried faking things out by creating a wpath class in the filesystem namespace, but gave up and created a mapped file class for windows that uses filesystem::path and CreateFileW.
I posted the issue with interprocess and Ion was of the opinion that this shorcoming needs to be addressed. I'm not sure if Steven is maintaining iostreams, or if he has given thought to how to address the iostreams implementation. My opinion is that boost libraries using paths in their interfaces should be using filesystem v3 paths. Beman, I think, suggested in the recent utf8 thread that boost libraries should use the wide version of the windows api passing path.wstring().c_str() where appropriate.
Do others have thoughts on this issue? Are the windows wide api usage part of boost guidelines? Should they be?
Thanks, Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This is actually the reason I avoided interprocess::mapped_file in one of my own projects some time ago. Use of the wide APIs under Windows is important if you are aiming for I18n.
El 25/02/2011 15:31, Jeff Flinn escribió:
I posted the issue with interprocess and Ion was of the opinion that this shorcoming needs to be addressed. I'm not sure if Steven is maintaining iostreams, or if he has given thought to how to address the iostreams implementation. My opinion is that boost libraries using paths in their interfaces should be using filesystem v3 paths. Beman, I think, suggested in the recent utf8 thread that boost libraries should use the wide version of the windows api passing path.wstring().c_str() where appropriate.
I wouldn't like to make Interprocess dependant on Filesystem just to handle paths, and the problem is not just related to mapped file, since some other Interprocess elements might require also wide string interface (like shared memory). So I'm afraid we need some kind of policy (and common code) to handle system calls with wide/utf-8 interfaces. This might require some heavy refactoring in Interprocess internals as there are some OS abstractions (file handling, unlink(), etc.) to simplify code and maintenance with narrow char interfaces.
Do others have thoughts on this issue? Are the windows wide api usage part of boost guidelines? Should they be?
AFAIK, we have no guidelines, Best, Ion
Ion Gaztañaga wrote:
El 25/02/2011 15:31, Jeff Flinn escribió:
I posted the issue with interprocess and Ion was of the opinion that this shorcoming needs to be addressed. I'm not sure if Steven is maintaining iostreams, or if he has given thought to how to address the iostreams implementation. My opinion is that boost libraries using paths in their interfaces should be using filesystem v3 paths. Beman, I think, suggested in the recent utf8 thread that boost libraries should use the wide version of the windows api passing path.wstring().c_str() where appropriate.
I wouldn't like to make Interprocess dependant on Filesystem just to handle paths, and the problem is not just related to mapped file, since some other Interprocess elements might require also wide string interface (like shared memory). So I'm afraid we need some kind of policy (and common code) to handle system calls with wide/utf-8 interfaces. This might require some heavy refactoring in Interprocess internals as there are some OS abstractions (file handling, unlink(), etc.) to simplify code and maintenance with narrow char interfaces.
Do others have thoughts on this issue? Are the windows wide api usage part of boost guidelines? Should they be?
AFAIK, we have no guidelines,
I was hoping to get more feedback from others on this topic. Wouldn't it be beneficial at least to address the file open issue? Jeff
On Feb 28, 2011, at 4:52 AM, Ion Gaztañaga wrote:
El 25/02/2011 15:31, Jeff Flinn escribió:
I posted the issue with interprocess and Ion was of the opinion that this shorcoming needs to be addressed. I'm not sure if Steven is maintaining iostreams, or if he has given thought to how to address the iostreams implementation. My opinion is that boost libraries using paths in their interfaces should be using filesystem v3 paths. Beman, I think, suggested in the recent utf8 thread that boost libraries should use the wide version of the windows api passing path.wstring().c_str() where appropriate.
I wouldn't like to make Interprocess dependant on Filesystem just to handle paths, and the problem is not just related to mapped file, since some other Interprocess elements might require also wide string interface (like shared memory). So I'm afraid we need some kind of policy (and common code) to handle system calls with wide/utf-8 interfaces. This might require some heavy refactoring in Interprocess internals as there are some OS abstractions (file handling, unlink(), etc.) to simplify code and maintenance with narrow char interfaces.
You say you don't want Interprocess dependant on Filesystem, but you also say Boost needs common code to handle system calls with wide/utf-8 interfaces. To me these are inconsistent statements. To me, Filesystem _is_ the common code (at least for paths, which is the majority of cases).
El 28/02/2011 20:29, Ian Emmons escribió:
You say you don't want Interprocess dependant on Filesystem, but you also say Boost needs common code to handle system calls with wide/utf-8 interfaces. To me these are inconsistent statements. To me, Filesystem _is_ the common code (at least for paths, which is the majority of cases).
It is not the common code for handling string conversions at OS level. The OS has many resources not related with paths: named semaphores, shared memory, named mutex, etc.. We need to handle all of them, filesystem handles strings for what its name says: filesystem. And filesystem uses locales associated with paths for that job, I don't know if that's the correct way to do it in Interprocess. Maybe it is, maybe it is not. At least for Interprocess, the easiest way is to offer wide string interface for OS that supports them (like windows). I don't know if names in narrow chars should be treated as utf-8, if all resource names should be treated as paths...Filesystem name encoding could be a valid example for other libraries, and it would be nice if such code could be taken out to be used for other named resources that also need such conversions, out of other filesystem resources like copying a file, etc. But anyway, I will study filesytem v3 to see if it's the answer. But sadly this has low priority in my to-do list. Best, Ion
participants (4)
-
Ian Emmons -
Ion Gaztañaga -
Jeff Flinn -
Joshua Boyce