On Thu, 10 Jul 2008, Andrew Whitworth wrote:
> I found this while tracking a nasty GC-related bug. In
> src/packfile/pf_items.c:PF_fetch_integer, we have the following two
> notes:
>
> XXX assumes C<sizeof (INTVAL) == sizeof (opcode_t) - we don't have
> INTVAL size in the PackFile header
>
> XXX assume sizeof (opcode_t) == sizeof (INTVAL) on the machine
> producing this PBC
>
> This raises the question, are the two always defined to be the same
> (which makes this a non-issue), or are there platforms where they are
> different? I suspect a fix would not be too too difficult if they
> aren't always the same, and if the behavior wasn't already implemented
> elsewhere.
I'm pretty sure that a very very long time ago, the configuration
sizeof(INTVAL) != sizeof(opcode_t) worked (or at least worked about as
well as any other configuration). The two "types" have logically
different roles, and so different sizes worked.
However, both "types" ought to be a flavor of integer that is at least 32
bits and that is "efficient" on the system running parrot. Practically
speaking, that means both probably ought to be the same size, and, indeed,
that's probably the only case that anyone ever runs.
Consequently, I suspect having different sizes probably hasn't
worked for years.
Curiously, though, Configure.pl does offer the option of picking different
sizes, and doesn't warn about it. Configure.pl *does* warn
if sizeof(INTVAL) != sizeof(void *).
Thus while it's probably generally true that sizeof(opcode_t) ==
sizeof(INTVAL), it's not enforced at the Configure.pl level.
In sort, it certinaly shouldn't be hard to include INTVALSIZE in the
PackFile header, but you can also probably "temporarily" stick an assert()
in there along with a note that perhaps Configure.pl ought to enforce this
equality.
--
Andy Dougherty [EMAIL PROTECTED]
