On Mon, Oct 13, 2014 at 6:09 PM, Armin Rigo <ar...@tunes.org> wrote: > > I think it should work.
I'm sure your right :) > What I have in mind for GUARD_GCTYPE would be > to check the GC header of the object; all GC pointers have one, with > our own GCs --- even GcArrays. So GUARD_GCTYPE would check that the > object is exactly of the correct type: the right kind of GcArray, or > the right kind of GcStruct that is not necessarily an RPython > instance. It would be inserted before we do more checks with that > pointer, whenever the pointer may originally be opaque. Are we certain opaque pointers always refer to GC-objects? > > Btw, a GUARD_CLASS on an opaque pointer that is not actually an > RPython instance may also crash, depending on the translation > settings. I think it works without problem if "gcremovetypeptr" is > True (the default on 64-bit, but not on 32-bit). If it is False, then > we have a very unlikely but possible false positive where the check is > done by reading the 2nd word of the object, just after the GC header, > and checking that it is exactly some value. If the object is > actually, say, a tuple of integers, then it would be possible that the > first integer has exactly the same value as expected. So unless I'm > missing something else, we have a potential bug that involves creating > a range(a, b, c) with a being exactly the same as the address of some > vtable thing... Right, but mark_opaque_ptr prevents this case as well by not moving operations using opaque pointers into the short preamble. So I guess we are currently fine? -- Håkan Ardö _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
