[Boost-bugs] [Boost C++ Libraries] #4576: Filesystem v3 does not respect NULL-terminated C strings whose size is known at compile time

Subject: [Boost-bugs] [Boost C++ Libraries] #4576: Filesystem v3 does not respect NULL-terminated C strings whose size is known at compile time
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-08-19 23:38:09

#4576: Filesystem v3 does not respect NULL-terminated C strings whose size is
known at compile time
---------------------------------------------+------------------------------
 Reporter:  Nate Silva <nate@…>              |       Owner:  bemandawes 
     Type:  Bugs                             |      Status:  new        
Milestone:  To Be Determined                 |   Component:  filesystem 
  Version:  Boost 1.44.0                     |    Severity:  Showstopper
 Keywords:                                   |  
---------------------------------------------+------------------------------
 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4576>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.