The issue is that the GC does not do any kind of initialization of allocated length, which is a key thing for safe appending to work. That is done strictly in the array allocation routine. So appending to anything you allocated with malloc or calloc, regardless of typeinfo, would be using an uninitialized allocated length, and would be bad.
-Steve ----- Original Message ---- > From: Sean Kelly <[email protected]> > To: Discuss the phobos library for D <[email protected]> > Sent: Wed, July 14, 2010 11:44:20 AM > Subject: Re: [phobos] custom BlkAttr flags > > But in both cases, TypeInfo could be supplied (either at the point of >allocation or set later). A bit would be more efficient however. Regarding >how this would all work, I was thinking of redefining calloc as: > > void* calloc(TypeInfo ti, size_t count); > > So the TypeInfo would replace the 'size' argument from C. This makes calloc > a >lot more useful than just "malloc with bzero" as it is now. > > On Jul 14, 2010, at 3:26 AM, Steve Schveighoffer wrote: > > > I added the fix for the comma, sorry for that. All the other places had > > an > > ALL_BITS enum member, so the NO_MOVE line that I copied and changed had a > > comma. I thought I compiled before I checked in, but I guess I did not. > > > > Regarding the bit being flipped, yes I want the default meaning to be "no > > append" because anyone can allocate memory via GC.malloc for any purpose, >and > > > GC.malloc does not initialize the "allocated length" field inside the > > block, >so > > > it is not appendable. It does not mean you cannot append to the block, it >just > > > means the first append will reallocate into an appendable block. > > > > Regarding using the typeinfo, that doesn't work. Arrays can easily be >created > > > out of blocks that weren't allocated via the array creation routines. > > Think >of > > > void[], and GC.malloc above. > > > > -Steve > > > > > > > > > > ----- Original Message ---- > >> From: Sean Kelly <[email protected]> > >> To: Discuss the phobos library for D <[email protected]> > >> Sent: Wed, July 14, 2010 12:25:09 AM > >> Subject: Re: [phobos] custom BlkAttr flags > >> > >> On Jul 13, 2010, at 8:09 AM, Steve Schveighoffer wrote: > >>> > >>> 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. > >> > >> Your checkin doesn't compile. I added the requisite comma for now to > >> fix > >> this. That aside, assuming this design were to be kept I think the >meaning of > > >> the bit has to be flipped. The bit defaults to unset, so that should be >the > > >> default meaning. You really don't want all blocks to be appendable by >default, > > >> do you? More generally, if we start holding TypeInfo references in the > >> GC >then > > >> we should be able to determine appendabiility based on whether the >TypeInfo is > > >> an array type. This may not make the next release, but I'd like to >address it > > >> once I've polished std.concurrency a bit more. > >> _______________________________________________ > >> 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 > _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
