Filesystem v3 does not respect NULL-terminated C strings whose size is known at compile time

[Nate Silva <nate@…>]

If a boost::filesystem version 3 path is constructed from a char* (or wchar_t*) buffer that has a size known at compile time, the entire buffer, except for the very last character, is appended to the path.

If, however, the buffer is dynamically allocated, then the NULL-terminator is respected.

If you construct a path from a string literal, it will work, however it is not clear whether it works correctly by design, or because the final character (the NULL-terminator) is dropped:

boost::filesystem::path("./foo");

If you construct it from a buffer whose size is known at compile time, the path unexpectedly contains the entire buffer (minus the final character) -- the NULL-terminator is ignored:

char buffer[255] = "./foo";
boost::filesystem::path p(buffer);
assert(p.string().size() == 254);    // should be 5!

If you construct it from a buffer which is dynamically allocated, the NULL-terminator is respected:

char *buffer2 = new char[255];
std::fill(buffer2, buffer2 + 255, '\0');
strcpy(buffer2, "./foo");
// N.B: This buffer is now identical to the buffer in the example above,
// but boost::filesystem treats it differently.
boost::filesystem::path p2(buffer2);
assert(p2.string().size() == 5);
delete [] buffer2;

This is a very serious problem, as it's common to use a fixed-length buffer to retrieve paths from OS APIs (e.g. MAX_PATH and SHGetFolderPath() in Windows). If a programmer instantiates a filesystem::path from that buffer, they will get unexpected results.

[Nate Silva <nate@…>]

Test case showing the problem.

[Nate Silva <nate@…>]

Also should mention that I’ve tested this on Visual C++ 10 (Windows 7) and on gcc 4.2.1 (OS X 10.6).

[Nate Silva <nate@…>]

Example showing unexpected results (Windows-specific)

[Beman Dawes]

I suspect this is the problem fixed by changeset 64928.

See ​http://svn.boost.org/trac/boost/changeset/64928

Does the change to path_traits.hpp solve your problem?

--Beman

[Nate Silva <nate@…>]

Yes, that does solve the problem on OS X. I will test with Windows tomorrow.

Regards, Nate

[Nate Silva <nate@…>]

And, this solves the problem on Windows as well.

Problem is fixed as far as I'm concerned.

Regards,
Nate