[phobos] custom BlkAttr flags

Steve Schveighoffer schveiguy at yahoo.com
Tue Jul 13 08:09:16 PDT 2010


Currently, there is a problem in the runtime which can result in very odd 
behavior.  Let's say you declare a class like this:

class C
{
   int[1] x;
}

Now, let's say you do something like this:

auto c = new C;
auto x = c.x[];
x ~= 1;

What happens here?  Well, the memory for c and  c.x are on the heap, so the 
block allocated by c is considered for appending, and a "length" field is looked 
at, even though that length is possibly garbage.  The result is that it's 
extremely improbable, but possible, that the append could happen in place if 
that "length" happens to be correct (thereby overwriting other members of c).  I 
can't even begin to construct a case which shows this is possible, and it may 
not even be, but I think this needs attention.

In addition, if anyone allocates memory via GC.malloc, and then tries to append 
to such memory, a similar problem occurs, because the allocation did not go 
through the array allocation routine.  This is more provable, but less likely to 
happen (most people don't call GC.malloc).  However, a place where I am most 
concerned is closures, which I think call GC.malloc.

What I propose to fix this is to allocate one of the block attribute flags to 
designate that a block is appendable.  The odd part about it, is that the GC is 
not aware of appending, so it is somewhat of a "user-defined" flag.

My question is, how should we declare the flag?  I currently only defined it in 
lifetime.d, outside the gc, but I'm thinking it should be defined in the GC as 
well.  Also, should I allocate the next bit, or one of the higher order bits?

I'm going to check in my code that defines it in lifetime.d only, and depending 
on the responses to this, I'll add it to the GC definition too.

-Steve



      


More information about the phobos mailing list