Hi!
Please consider the code below:
=== BUG ===
boost::filesystem::path some_path("first");
char path_component[1]; /* = "second" */
some_path /= path_component;
Some_path value is expected to be "first/second" but it is "first".
I.e operator /= had no effect.
=== END BUG ===
Concerning a longer string in a char[1] buffer.
Actually path_component is the *last* field in a heap-allocated structure.
The structure is over-allocated to enable storing a longer string in a char[1] buffer.
This technique is often used in C code.
Here is operator /= callstack.
#0 boost::filesystem3::path_traits::empty () at path_traits.hpp:89
#1 0x0000000100001e7e in boost::filesystem3::path::append (this=0x7fff5fbff910, source=@0x100100270, cvt=@0x100100280) at path.hpp:655
#2 0x0000000100001f77 in boost::filesystem3::path::operator/= (this=0x7fff5fbff910, source=@0x100100270) at path.hpp:235
The relevant excerpt from boost::filesystem3::path_traits::empty follows:
namespace path_traits {
...
template inline
bool empty(T (&)[N])
{ return N <= 1; }
...
}
It appears that boost::filesystem::path treats char[1] as an empty path regardless of the actual content.
This is definitely wrong due to so many C libraries storing long strings in char[1] buffers.
In particular on Mac OS X fts(3) FTSENT::fts_name is char[1].
I believe the current operator =/ behavior is outright dangerous and should be fixed.
By the way the only code currently benifiting from the boost::filesystem::path being overly smart is the code appending "" (empty string literal) to pathes.
