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]