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 <[email protected]> > To: Discuss the phobos library for D <[email protected]> > Cc: Phobos <[email protected]> > 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 <[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 > _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
