Re: [Boost-users] [Filesystem] String corruption in path in V3 and Boost 1.44

Subject: Re: [Boost-users] [Filesystem] String corruption in path in V3 and Boost 1.44
From: Timothy Madden (terminatorul_at_[hidden])
Date: 2010-09-22 10:14:46

On 22.09.2010 13:15, Will Watts wrote:
>
> I have the following method:
>
> boost::filesystem::path Sfw::CFolders::GetModulePath()
> {
> char buffer[MAX_PATH+1];
> chknzapi (GetModuleFileName (NULL, buffer, MAX_PATH));
> return buffer; // Converted to fs::path object
> }
>
> Under Boost 1.43 this seemed to work fine. The char buffer is used to
> create a temporary path object, which is returned by value from the
> function.
>
> But when I upgraded to Boost 1.44, and recompiled with
> BOOST_FILESYSTEM_VERSION=3 and BOOST_FILESYSTEM_NO_DEPRECATED defined, I
> found that, although it still compiled, it no longer worked properly.
>
> Specifically, the contents of the path becomes corrupted to garbage. I
> got the impression that the path object returned, instead of containing
> a copy of the character string, retains a pointer to the original char
> buffer[] on the stack - which is naturally trampled on by subsequent
> activity.
>
> Changing the function to this:
>
> boost::filesystem::path Sfw::CFolders::GetModulePath()
> {
> char buffer[MAX_PATH+1];
> chknzapi (GetModuleFileName (NULL, buffer, MAX_PATH));
> return string(buffer);
> }
>
> seems to fix the problem.
>
> I admit I have not examined the code for the filesystem::path class - I
> am roundly intimidated by Boost code.
>
> Is my problem caused by a bug in the library introduced by 1.44, or am I
> just using the library incorrectly? Is my fixed version acceptable, or
> am I just 'lucky' that it seems to work?
[...]

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, 
and also directory iterators look like they are not working correctly in 
all cases (see a previous article in this group 
news://news.gmane.org:119/i5qkfu$7ke$[e-mail]).

Trying to build a minimal test case was unsuccessful for me as the bug 
did not reproduce. Maybe now that I know a local TCHAR [] array may 
help, I could try again.

Anyone else had problems with filesystem v3 paths or iterators ? 
Constructed from local char arrays ?

Will, thanks for the wstring() work-around :)

Thank you,
Timothy Madden