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: Lars Viklund (zao_at_[hidden])
Date: 2012-04-21 08:34:17

On Fri, Apr 20, 2012 at 07:15:53PM +0200, Ovanes Markarian wrote:
> 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...

The trick in C is to malloc the struct with a larger size. A canonical
example is:

  typedef struct S { size_t bytes; char flex[1]; } S;
  S* s = malloc(sizeof(S) + (amount-1));
  s->bytes = amount;

That is, you have bonus bytes after the struct which you can access
through the last struct member. Variants on this is to use a
zero-length-array in the language dialects that support it.

It's a very common way of allocating a variable-size array with bundled
size in a single chunk, which makes cleanup a single free() and gives
you some coherence between the size and data.

In that world, it's perfectly sane and rational to read past the end of
an array, and some compilers have explicit exceptions to reading past
the last element of an end-of-struct 1- or 0-sized array, just because
of this.

-- 
Lars Viklund | zao_at_[hidden]