[Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48

Subject: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48
From: Nick Zavaritsky (mejedi_at_[hidden])
Date: 2012-04-20 12:08:58

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<char const, 1ul> () at path_traits.hpp:89
#1  0x0000000100001e7e in boost::filesystem3::path::append<char [1]> (this=0x7fff5fbff910, source=@0x100100270, cvt=@0x100100280) at path.hpp:655
#2  0x0000000100001f77 in boost::filesystem3::path::operator/=<char [1]> (this=0x7fff5fbff910, source=@0x100100270) at path.hpp:235

The relevant excerpt from boost::filesystem3::path_traits::empty follows:

namespace path_traits {
  ... 
  template <typename T, size_t N> 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.