Re: treeiter stamp sign extension
- From: muppet <scott asofyet org>
- To: "gtk-perl-list gnome org List" <gtk-perl-list gnome org>
- Subject: Re: treeiter stamp sign extension
- Date: Tue, 2 Dec 2008 21:32:16 -0500
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]