Re: treeiter stamp sign extension

On Dec 1, 2008, at 6:40 PM, Kevin Ryde wrote:

In a custom TreeModel I was foolish enough to let my iter "stamp"
generation come up with a 32-bit value.  A cpan testers report on an
int=32bit long=64bit system had me making 0x807012D8, but after storing that to a TreeIter then getting it back in an arrayref to a method call
the array had instead 0xFFFFFFFF807012D8.

You've fallen prey to perl's IV being defined as an integer large enough to hold a pointer. So, even though the platform is sizeof(int)=4, sizeof(IV) will be 8 because sizeof(void*)=64.

To be honest, this isn't something we considered when wrapping that stuff.

I think it's a case of "don't do that" on my part, but are stamps meant to be treated unsigned and zero extended (even though the C is a signed
gint of course)?

I doubt anybody actually considered that.

On an int==long==32bit or int==long==64bit I guess stamps are always
seen unsigned at the perl level, and there's no extension to worry
about. But when gint is 32bit and UV is 64bit I wonder if it might want
some casts [untested!], in sv_from_iter()

   av_push (av, newSVuv ((guint) iter->stamp));

and maybe in to_arrayref() truncate for the compare [also untested!]

   if (iter->stamp != (gint) stamp)

If you don't mind testing that out, i think that's probably the best approach.

Diane, ten-oh-three, Great Northern Hotel.
Sheriff Truman and I have just been with the one-armed man, or what's left of him. In another time, another culture, he may have been a seer, or a shaman priest, but in our world, he's a shoe salesman, and lives among the shadows.
-- Special Agent Dale Cooper

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]