Hello Nick, please see my answer below. On Fri, Apr 20, 2012 at 6:08 PM, Nick Zavaritsky 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 () 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.

Regards, Ovanes