Hi Beman,

PS: I'd like to hear from programmers using wide character file names. Are they working OK? Are they meeting your needs?

I have been updating a windows application (using MSVC7.1, 13.10.3077, and the latest cvs) to support wpaths. It all works pretty much as expected and it didn't take much time to make the changes. Let me list a few things I've found so far. == fstream_test asserts All the tests pass, except for the fstream_test. Here's the output: execute-test ..\..\..\bin\boost\libs\filesystem\test\fstream_test.test\vc-7_1\debug\threa ding-multi\fstream_test.run ====== BEGIN OUTPUT ====== path tests: in test 1 in test 2 in test 3 in test 4 in test 4.1 in test 5 in test 6 in test 7 in test 8 in test 9 in test 10 in test 11 in test 12 in test 13 in test 14 in test 15 wpath tests: in test 1 in test 2 in test 3 in test 4 in test 4.1 C:\cvs\boost\boost/test/minimal.hpp(122): exception "fopen.c(55) : Assertion failed: *file != _T('\0')" caught in function: 'int __cdecl main(int,char *[])' == missing inline (multiple defined symbols) There seems to be an inline missing in fstream.hpp (line 45) for the narrow_path() call. == openmode differences for path/wpath I ran into a few calls where fs::ofstreams where opened in binary mode, but the std::ios_base::out flag wasn't specified. This worked fine for paths, but for wpaths this was giving asserts as the narrow_path() function specifically checks for this flag. template<typename Path> void test_no_out_mode(Path const& p) { fs::remove(p); fs::ofstream str(p, std::ios_base::binary); BOOST_CHECK(!!str); BOOST_CHECK(fs::exists(p)); } void test_out_mode_narrow() { test_no_out_mode(fs::path("new_file_narrow")); } void test_out_mode_wide() { // asserts, unless you specify std::ios_base::out as well test_no_out_mode(fs::wpath(L"new_file_wide")); } Thanks again, Arjen

Hi Beman,

...

== openmode differences for path/wpath

I ran into a few calls where fs::ofstreams where opened in binary mode, but the std::ios_base::out flag wasn't specified. This worked fine for

paths,

...

but for wpaths this was giving asserts as the narrow_path() function specifically checks for this flag.

Good catch. CVS has been changed to OR in the correct flag. The problem also affected ifstreams and fstreams.

I've just checked with the latest CVS and the test_out_mode_wide() case (see below) still fails (on windows). The file is not created. In fstream.hpp(369) a call is made to detail::path_proxy with a mode parameter without the std::ios_base_out flag. This flag is checked in fstream.hpp(57). --- snip template<typename Path> void test_no_out_mode(Path const& p) { fs::remove(p); fs::ofstream str(p, std::ios_base::binary); BOOST_CHECK(!!str); BOOST_CHECK(fs::exists(p)); } void test_out_mode_narrow() { test_no_out_mode(fs::path("new_file_narrow")); } void test_out_mode_wide() { test_no_out_mode(fs::wpath(L"new_file_wide")); } filesystem_unit.cpp(33): error in "filesystem_test::test_out_mode_wide": heck !!str failed filesystem_unit.cpp(34): error in "filesystem_test::test_out_mode_wide": heck fs::exists(p) failed --- snip Regards, Arjen

Hi Beman,

PS: I'd like to hear from programmers using wide character file names. Are they working OK? Are they meeting your needs?

I tested directory_iterator and fstream for Chinese file names on Windows XP Japanese edition. directory_iterator worked correctly, but fstream didn't. In detail::narrow_path_api(), GetShortPathNameW() is used for getting the short 8.3 form names. This function returns an Unicode string which contains non-ASCII characters. So, mapping from Unicode to ANSI is necessary. Please see the the attachment. Regards, Takeshi Mouri

Hi Beman,

...

I tested directory_iterator and fstream for Chinese file names on Windows XP Japanese edition. directory_iterator worked correctly, but fstream didn't.

Thanks Takeshi. I'll give your patch a try tomorrow.

Do you have a test case you would like to see added to the regression test?

Woops! I had forgotten to write the test case. I tested this by VC7.1 and VC8. #include <boost/filesystem/fstream.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> #include <boost/test/unit_test.hpp> #include <locale> // Japanese Hello const wchar_t hello_jp[] = L"\u3053\u3093\u306B\u3061\u306F.txt"; // Chinese Hello const wchar_t hello_cn[] = L"\u4F60\u597D.txt"; namespace fs = boost::filesystem; namespace ut = boost::unit_test; void test_unicode_path_fstream_aux(const fs::wpath& ph) { fs::remove(ph); // open and write 3 bytes fs::ofstream os(ph); os << "abc" << std::flush; os.close(); // check by "true" Unicode function BOOST_CHECK_EQUAL(fs::file_size(ph), 3); fs::remove(ph); } void test_unicode_path_fstream() { // Dinkumware's fstream requires this for non-ASCII filename std::locale::global(std::locale("")); test_unicode_path_fstream_aux(fs::wpath(hello_jp)); test_unicode_path_fstream_aux(fs::wpath(hello_cn)); } ut::test_suite* init_unit_test_suite(int, char* []) { ut::test_suite* test = BOOST_TEST_SUITE("test wpath fstream"); test->add(BOOST_TEST_CASE(&test_unicode_path_fstream)); return test; } Regards, Takeshi Mouri

Hi Beman,

...

In detail::narrow_path_api(), GetShortPathNameW() is used for getting the short 8.3 form names. This function returns an Unicode string which contains non-ASCII characters. So, mapping from Unicode to ANSI is necessary.

This is a tough one for me; the test cases you sent separately work fine on my Win XP SP2 English edition. The differences in test results may have more to do with codepage differences that edition differences.

Yes. For example, my test results: Case A: (Japanese Only) L"\u3053\u3093\u306B\u3061\u306F.txt" -> L"\u3053\u3093\u306B~1.TXT" Case B: (Chinese, but contains CJK Unified Ideograph) L"\u4F60\u597D.txt" -> L"\u597DD0E7~1.TXT" Case C: (Chinese Only) L"\u4F60\u597D.txt" -> L"7464~1.TXT" I think that your environment corresponds to the case C.

In any case, I applied your patch to CVS.

Thanks! Regards, Takeshi Mouri

small feature request: a member function: void basic_path::clear(); This fits in with having member functions like basic_path::empty() const, indeed all the STL classes that I can think of with an empty() member function also have a clear() member function. Okay, queue and priority_queue don't, but I think that they should too. This might mean a small change to TR2 proposal. "Beman Dawes" <bdawes@acm.org> wrote in message news:dtl9pn$4vo$1@sea.gmane.org...

"Mark Bartosik" <mbartosik@yahoo.com> wrote in message news:dtjclm$7dr$1@sea.gmane.org...

...

bug in filesystem::wpath. In mirgrating to support wchar_t, a couple of lines were missed. m_path which has type of std::wstring is assigned a narrow character string resulting in a compilation error.

Fixed in CVS. Test cases were also added to wide_test.cpp.

Thanks,

--Beman

PS: I'd like to hear from programmers using wide character file names. Are they working OK? Are they meeting your needs?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Arjen Wagenaar" <arjenw@chello.nl> wrote in message news:20060302132148.VZED21085.amsfep14-int.chello.nl@codeshop6ftss7...

Hi Beman,

...

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: donderdag 23 februari 2006 22:35 To: boost@lists.boost.org Subject: Re: [boost] bug in filesystem::wpath

PS: I'd like to hear from programmers using wide character file names. Are they working OK? Are they meeting your needs?

I've just found that system_complete() doesn't work for wpaths (on windows). Reason is that the stack gets corrupted in a call to GetFullPathNameW().

In the function get_full_path_name_template (operations.cpp:382), a call is made to get_full_path_name. The parameter passed specifying the size of the buffer should be buf_size, instead of sizeof(buf).

Fixed in CVS. Thanks! --Beman