[phobos] custom BlkAttr flags

[Steve Schveighoffer]

No, because typeinfo has nothing to do with whether you allocated a block of 
memory using an array allocation routine or GC.malloc.

I need a bit.  I've used the next one in line, hopefully that's OK (the code is 
already checked in).

-Steve



----- Original Message ----
> From: Sean Kelly <sean at invisibleduck.org>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Cc: Phobos <phobos at puremagic.com>
> Sent: Tue, July 13, 2010 8:21:45 PM
> Subject: Re: [phobos] custom BlkAttr flags
> 
> 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
> _______________________________________________
> phobos  mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>