appending fixed-size array of length 1 is a no-op in path v3

[mejedi@…]

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

struct c_struct
{
    int foo;
    int bar;
    char flexible_buf[1];
};

c_struct *p = malloc(sizeof *p + EXTRA);

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.

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.

An example is fts(3) ​http://www.kernel.org/doc/man-pages/online/pages/man3/fts.3.html. 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.

[Beman Dawes]

(In [78136]) Filesystem: Fix #6819; 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.