please see my answer below.
On Fri, Apr 20, 2012 at 6:08 PM, Nick Zavaritsky
<mejedi@gmail.com> wrote:
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.
I think the idea behind this is that any char* related string must be null terminated. So char[1] has only place for '\0'...
=== 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.
This over-allocation is pretty much the same as reserving some space at the end of the data structure to place data together. Am I right? Why isn't it possible to just write char[128] or char[16] instead of char[1]? And if you know that this buffer represents some special case, why don't you pass it as such to filesystem? &char[0], than boost::filesystem will not assume it got char[1] and will be looking to '\0' marker...
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.
Regards,
Ovanes