id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
4576,Filesystem v3 does not respect NULL-terminated C strings whose size is known at compile time,Nate Silva <nate@…>,Beman Dawes,"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.",Bugs,closed,To Be Determined,filesystem,Boost 1.44.0,Showstopper,fixed,,