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

Subject: Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2012-04-20 13:15:53

Hello Nick,

please see my answer below.

On Fri, Apr 20, 2012 at 6:08 PM, Nick Zavaritsky <mejedi_at_[hidden]> 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