[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