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