GNOME Bugzilla – Bug 684331
Fix GValue marshalling of long and unsigned long
Last modified: 2012-10-15 13:02:39 UTC
long can be equivalent to int64 or int32, depending on the architecture, and GI conflates this distinction in the typelib, but GType does not, and warns if the wrong accessor is used.
Created attachment 224677 [details] [review] Fix GValue marshalling of long and unsigned long
Thanks! There is a typo in the first hunk (you meant to say _long, not _int), otherwise this looks good. I'll commit this after the freeze.
Also, I think the second and fourth hunk is wrong. get_long() for an int64 type would clip the upper half on architectures where long is 32 bits; I don't know of such architectures, but if they exist the current code looks correct.
Created attachment 224696 [details] [review] Fix GValue marshalling of long and unsigned long Attaching the corrected patch. Thanks!
Review of attachment 224696 [details] [review]: ::: gi/pygi-argument.c @@ +2010,3 @@ break; case GI_TYPE_TAG_INT64: arg.v_int64 = g_value_get_int64 (value); why did you remove "break"?
Created attachment 224697 [details] [review] Fix GValue marshalling of long and unsigned long Because I forgot to do format-patch after "commit --amend" again, sorry. Thanks for spotting!
(In reply to comment #3) > Also, I think the second and fourth hunk is wrong. get_long() for an int64 type > would clip the upper half on architectures where long is 32 bits; I don't know > of such architectures, but if they exist the current code looks correct. long is the size of a pointer (usually), so it's 32 bits in x86. But in that case GI would mark it (u)int32, so that branch would never be hit. On the other hand, current code is wrong in the interesting case (x86_64), were long is marked (u)int64 but using the int64 accessors causes a critical.
Created attachment 224803 [details] [review] Fix Ah, thanks for the additional explanation. So, attaching your first patch again with only the _int -> _long typo fixed. Curiously, I've never seen this warning. In which kind of code did you encounter this, some property declared as long type? I thought we had a fairly good coverage of data types in the tests; I'd like to add a test case for this, but if you could point me to something that reproduces this it would help. Thanks!
Found in signal emission of RbExtDB::request in Rhythmbox, which has a G_TYPE_ULONG parameter.
Comment on attachment 224803 [details] [review] Fix Committed, fix will be in 3.4.1. Thanks!
*** Bug 685551 has been marked as a duplicate of this bug. ***
The Debian BTS tracks this issue in bug #660113 [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660113