https://svn.boost.org/trac10/ticket/6819 <p> Boost::filesystem::path recognizes appending a fixed-size array of length 1 as a special case and does nothing. This looks pretty reasonable until you consider using boost::filesystem together with C libraries. In C a common trick is to allocate a structure AND a character buffer with a single call to a memory allocation routine. The structure is often declared and allocated as follows </p> <div class="wiki-code"><div class="code"><pre><span class="k">struct</span> <span class="n">c_struct</span> <span class="p">{</span> <span class="kt">int</span> <span class="n">foo</span><span class="p">;</span> <span class="kt">int</span> <span class="n">bar</span><span class="p">;</span> <span class="kt">char</span> <span class="n">flexible_buf</span><span class="p">[</span><span class="mi">1</span><span class="p">];</span> <span class="p">};</span> <span class="n">c_struct</span> <span class="o">*</span><span class="n">p</span> <span class="o">=</span> <span class="n">malloc</span><span class="p">(</span><span class="k">sizeof</span> <span class="o">*</span><span class="n">p</span> <span class="o">+</span> <span class="n">EXTRA</span><span class="p">);</span> </pre></div></div><p> Consider a C library exposing a structure similar to c_struct and a piece of C++ code appending flexible_buf to a path object. This will result in a hard to find bug since a programmer is probably assuming that appending a string to a path object will actually append a string. </p> <p> To make matters worse a casual user of a C library is not even aware that the library is playing the flexible buffer trick. Library docs may pretend that the structure has a character pointer field but the implementation declares a char[1] field instead. </p> <p> An example is fts(3) <a class="ext-link" href="http://www.kernel.org/doc/man-pages/online/pages/man3/fts.3.html"><span class="icon">​</span>http://www.kernel.org/doc/man-pages/online/pages/man3/fts.3.html</a>. Manual pretends that fts_name is a character pointer field in _ftsent struct but on Linux and MacOS X fts_name is char[1] instead. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/6819 Trac 1.4.3 mejedi@… Sat, 21 Apr 2012 20:20:09 GMT https://svn.boost.org/trac10/ticket/6819 https://svn.boost.org/trac10/ticket/6819 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">path.cpp</span> </li> </ul> Ticket Beman Dawes Sun, 22 Apr 2012 15:07:14 GMT https://svn.boost.org/trac10/ticket/6819#comment:1 https://svn.boost.org/trac10/ticket/6819#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> (In <a class="changeset" href="https://svn.boost.org/trac10/changeset/78136" title="Filesystem: Fix #6819; A path operand with a source that was a one ...">[78136]</a>) Filesystem: Fix <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/6819" title="#6819: Bugs: appending fixed-size array of length 1 is a no-op in path v3 (closed: fixed)">#6819</a>; A path operand with a source that was a one character array was treated as empty, even if it wasn't empty. Such arrays can occur and be non-empty in unions or in code using C variable length array idioms. </p> Ticket