On 22.09.2010 18:10, Will Watts wrote:

In article, Timothy Madden wrote:

...

I have a similar problem with remove_all(), that is also fixed with a wstring (actually path::string_type) instead of a local TCHAR [] buffer,

Aha - so we both think it is probably a bug, then? If nothing else, it is certainly a trap.

Do you happen to know if the Filesystem maintainer monitors this list, or if we should be making our case elsewhere?

Yes, I think it is a bug. My code also worked with V2 and boost 1.43, and after upgrading to V3 and 1.44 it crashed. I do not know about the Filesystem maintainer, but we need a minimal example to reproduce the problem to make our case elsewhere, that is on the bug tracker or on another list. Timothy Madden

On 22.09.2010 20:36, Will Watts wrote:

In article, Timothy Madden wrote:

...

I do not know about the Filesystem maintainer, but we need a minimal example to reproduce the problem to make our case elsewhere, that is on the bug tracker or on another list.

How about this?

void main() { const char * f = "foo"; char b[5]; strcpy(b, f); fs::path p1(b); // Debugger shows p1.m_pathname.size = 4 after this fs::path p2(f); // But p2.m_pathname.size = 3 cout<< p1<< endl; // prints "foo " cout<< p2<< endl; // prints "foo" cout<< (p1 == p2)<< endl; // prints 1 - they are supposedly identical }

Please can you check that I haven't cocked up the strcpy(), or something idiotic! By all means repeat the exercise with wide characters.

This doesn't show a spectacular crash, but I think it shows that something is amiss with the C array handling - something to do with the terminating zero byte? What do you reckon?

I think that somehow the template constructor for paths takes the entire array passed as argument and not just the null-terminated string inside the array, which may be smaller. I also got a crash with the attached code on Visual Studio 2008. I have created a track ticket https://svn.boost.org/trac/boost/ticket/4677, lets hope someone picks it up. Timothy Madden

In article , Timothy Madden wrote:

I think that somehow the template constructor for paths takes the entire array passed as argument and not just the null-terminated string inside the array, which may be smaller.

This seems to be bang on, as does Scott's speculation as to how it came about. I made a variation of my original experiment, which demonstrates it: const char * f = "foo"; const char * g = "bar"; char b[10]; strcpy(b, f); strcpy(b + strlen(f) + 1, g); // b contains 'f','o','o',0,'b','a','r', 0, Garbage, Garbage fs::path p1(b); // p1.m_pathname.size = 9 fs::path p2(f); // p1.m_pathname.size = 3 // prints "foo bar?" where ? is 8-bit garbage character cout << p1 << endl; // prints "foo" cout << p2 << endl; cout << (p1 == p2) << endl; // prints 1 The last line proves that in some circumstances the nul byte is ignored, in others it is treated as significant. I am surprised the path class can 'know' the length of a C array. I guess that's the magic of templates for me.

I also got a crash with the attached code on Visual Studio 2008. I have created a track ticket https://svn.boost.org/trac/boost/ticket/4677, lets hope someone picks it up.

Top work! Will

In article , Scott McMurray wrote:

It's actually quite simple:

So it is - <blush>. Thanks for the education. Will