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