[Sc-devel] [] can cause instability: tests in primitives?

[James McCartney]

On 11/21/07, Stefan Kersten <sk at k-hornz.de> wrote:
> On 21.11.2007, at 16:51, Dan Stowell wrote:
> > wrapAt's primitive uses basicWrapAt(), and plot uses unlace which uses
> > prArrayUnlace(), both in PyrArrayPrimitives.cpp. Looks like they both
> > fail to account for an empty array.
> >
> > Could there be some generic way to catch these problems? e.g. this
> > line could (I guess) return nil if empty:
> >
> >  if(obj->size==0) {SetNil(a); return errNone; }
>
> yes, basicWrapAt is missing the check for obj->size == 0, also for
> the array-as-index case.
>
> > but would need slightly different versions adding to each primitive.
> > Any better way?
>
> the solution wouldn't be quite correct for unlace:
>
> [].unlace(3)
>
> [[],[],[]]
>
> i guess (jmc will correct me if i'm wrong), that the newly created
> subarrays (and the result array) need to be reconsidered by the
> garbage collector:
>
>         SetObject(slots2 + i, obj3);
>         g->gc->GCWriteNew(obj2, obj3);
>
> , likewise for the sublist elements:
>
>         PyrSlot* tmp = slots + (i*clump + k + j*numLists);
>         slots3[j+k].ucopy = tmp->ucopy;
>         g->gc->GCWrite(obj3, tmp->uo);
>
> [ cannot test properly now, still at work :P ]
>
> <sk>

Objects are allocated white (meaning that it is unknown whether they
are live or dead). GCWrite is meant to protect against a black to
white pointer which is a violation of the incremental collection
invariant: a known live object which has been scanned (black) may only
point to other black objects or objects which are pending being
scanned (gray).

You are free to set slots in a newly allocated white object without
calling GCWrite because the newly allocated object cannot be black. If
you allocate a second object and the collect argument is true then the
above no longer holds since the collection during allocation may mark
your previously white object to gray or black.


-- 
--- james mccartney