[phobos] custom BlkAttr flags

[Andrei Alexandrescu]

Idea: you can easily accommodate allocation of structs by wrapping them 
in a class:

S * allocateStruct(S)()
{
     class Classify { S payload_; }
     auto result = new Classify;
     return &result.payload_;
}

That works with the existing GC which knows how to collect classes.

Another, cheaper variant which assumes arrays are GCd properly:

S * allocateStruct(S)()
{
     return (new S[1]).ptr;
}


Andrei

On 07/13/2010 07:21 PM, Sean Kelly wrote:
> 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