$ cat e.pasm new P0, .Random new P1, .Random new P2, .PerlInt bxor P2, P0, P1 print P2 print "\n" end
One would expect (and got until yesterday): $ parrot e.pasm bitwise_xor() not implemented in class 'Random'
But depending on the registered MMD class type range (and actually now) we get:
$ parrot e.pasm 1796904200
or some such. The PMC has a get_integer vtable method which is called by the mmd_fallback function for MMD_BXOR and the rather meaningless operation happily runs (Random could be a more non-mathematical PMC that happens to have a get_integer vtable method).
And, if a PASM MMD function is registered, the type range may be suddenly covered by MMD functions and the fallback method gets called then. This would change the behavior of the opcode at runtime:
bxor PerlInt, Array, Array # unimplemented mmd_vtregister .MMD_BXOR, 100, 100, TheSub # some user class
now bxor of array PMCs is suddenly valid and gives the xor of the array sizes.
I think we need special treatment of all the Parrot_default_<meth> slots that now fail with "unimplemented" (see classes/default.c)
leo
