On Wed, 25 Feb 2004, Dan Sugalski wrote:
> At 4:54 PM -0500 2/25/04, Simon Glover wrote:
> > If I'm understanding the docs correctly, this should print '0'.
> > Instead, it prints 'Array index out of bounds!'
>
> Another bug, though the offset ought to be 2 right now. (Attributes 0
> and 1 are taken by other things so they're valid)
OK, I think I see what's going on now: attribute 0 is the class PMC,
attribute 1 is the classname PMC, and then any other attributes go
into slots 2+
However, there's currently nothing to stop you stomping on the PMCs
in slots 0 and 1 by setting attributes with those offsets: in other
words, doing:
newclass P1, "Foo"
addattribute P1, "i"
find_type I0, "Foo"
new P2, I0
new P3, .PerlInt
set P3, 1024
setattribute P2, 1, P3
works, but changes the classname PMC to be a PerlInt with a value of
1024. Are we supposed to be able to do this?
A second issue (and what confused me in the first place) is that in your
attribute example in PDD 15 you have:
Adding the attributes C<a> and C<b> to the new class C<Foo>:
newclass $P0, "Foo"
addattribute $P0, "a", "Foo::a" # This is offset 0
addattribute $P0, "b", "Foo::b" # This is offset 1
I assume that this should actually refer to offsets 2 and 3?
Finally, in looking at the ops code, I noticed an unrelated bug:
in the classname op, you do:
classname_pmc = VTABLE_get_pmc_keyed_int(interpreter,
(PMC *)PMC_data($2), POD_CLASS_NAME);
To get the classname for the PMC. The problem is that the op is
documented as working with a PMC respresenting a class, but you're
using the symbolic constant from the object enum. This currently works,
since the classname PMC is stored in slot 1 in both a ParrotObject and
a ParrotClass PMC, but it still looks like a bug.
Simon
