treeiter stamp sign extension

[Kevin Ryde <user42 zip com au>]

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.

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)?

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)



Couple of lines below which might, maybe, perhaps, possibly, if you're
lucky, provoke the problem if anyone has access to an int=32 long=64.

use strict;
use warnings;
use Gtk2;

my $stamp = 0x8000_0000;
print "intended stamp $stamp\n";

my $iter = Gtk2::TreeIter->new_from_arrayref ([$stamp,0,undef,undef]);
my $aref = $iter->to_arrayref ($stamp);

print "aref got stamp ", $aref->[0], "\n";


-- 
"Pierpont, being the longest married and therefore the most gifted in
extemporaneous untruth, had a better solution."