[phobos] custom BlkAttr flags

[Sean Kelly]

The GC is going to need a bit of an overhaul to support finalization of structs anyway. Maybe this could be another use for the stored typeinfo. 

Sent from my iPhone

On Jul 13, 2010, at 8:09 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:

> 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
> 
> 
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos