On Mon, 7 Jul 2008, Andrew Whitworth via RT wrote:
> On Thu Mar 13 18:06:21 2008, doughera wrote:
> > I don't know if those calculations are still correct, now that strings
> > are not "bufferlike".
>
> Most of the memory management code uses a cast to (Buffer *) or (PObj *)
> to test a generic object's flags field. So long as a particular item's
> flag field can be found in this method, the alignment of the rest of the
> item should neither be assumed nor expected. To that end, I would say
> that strings are indeed "bufferlike" because you can cast them to a
> buffer to test for the flags field.
>
> Maybe it's worthwhile for us to test the offset values of the flags
> field for each type of item (string, buffer, pobj, pmc, stack_chunk_t)
> to ensure they are properly aligned and interchangable, as the memory
> system treats them.
But each of those types explicitly starts with the same two elements
UnionVal cache;
Parrot_UInt flags;
so no casting is necessary to find the flags. Why do you need to do any
casting at all?
Now I'd certainly agree that this requirement should be documented in the
pobj.h and stacks.h header files, and I could easily imagine either a
'coding-standard' type test (as part of C<make test>) or a series of
asserts() somewhere in the parrot runtime to ensure that the structures
are as claimed, but for now, I think that if there's a problem finding the
flags, it's likely a side effect of a problem elsewhere.
My original post that started this thread had to do with interchanging the
position of the 'strstart' and 'bufused' elements in the parrot_string_t
structure. In principle, that shouldn't matter at all. In practice, it
caused parrot to die with an alignment error. I could well believe that
the alignment error was a consequence of some other error, and using the
word 'alignment' in the Subject line might, in hindsight, have been
misleading. However, the error went away if you padded the string
structure with an extra element, so it does indeed smell like an alignment
assumption somewhere. My first guess was that calculations involving
sizeof(Buffer) were now questionable, but that was just a guess.
--
Andy Dougherty [EMAIL PROTECTED]
