Re: treeiter stamp sign extension

[muppet <scott asofyet org>]

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