Hi Hakan, On 13 October 2014 13:10, Hakan Ardo <ha...@debian.org> wrote: > I think the problematic case is actually when mixing with arrays. > There will already be a guard_class protecting the getfiled in the > short preamble, but it crashes when operating on an array. Also, there > is no guard_arraytype. So mixing different types of arrays will crash. > There is logic to generate guards for the arraylen and place those in > short preamble.
I think it should work. 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. 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... This would also be resolved if in this case we put a GUARD_GCTYPE first (and then don't need an additional GUARD_CLASS). A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
