GNOME Bugzilla – Bug 685022
GLib-2.0.gir has wrong MININT64 and MAXUINT64 constants
Last modified: 2015-02-07 16:49:15 UTC
While debugging something else I noticed that GLib.MAXUINT64 and GLib.MININT64 are wrong: $ python -c 'from gi.repository import GObject, GLib; print GObject.G_MAXUINT64, GLib.MAXUINT64' 18446744073709551615 9223372036854775807 $ python -c 'from gi.repository import GObject, GLib; print GObject.G_MININT64, GLib.MININT64' -9223372036854775808 9223372036854775807 GObject's one is right, and represents the constants as you would get them in C. However, the introspected constants from GLib are wrong. This doesn't seem to be a bug in PyGObject, as other guint64 constants are correct: $ python -c 'from gi.repository import Gst; print Gst.BUFFER_OFFSET_NONE' 18446744073709551615 It seems GLib-2.0.gir itself is wrong: <constant name="MININT64" value="9223372036854775807" c:type="G_MININT64"> <type name="gint64" c:type="gint64"/> </constant> <constant name="MAXUINT64" value="9223372036854775807" c:type="G_MAXUINT64"> <type name="gint64" c:type="gint64"/> </constant> They both have a bogus c:type, and for MAXUINT64 the type is wrong as well (should be guint64).
Created attachment 225316 [details] [review] PyGObject test case Once this is fixed in g-i, I'll commit attached test case to PyGObject, to ensure that (u)int64 constants work all the way through.
Comment on attachment 225316 [details] [review] PyGObject test case I pushed the PyGObject test case together with a workaround; this seems like a too dangerous and unobvious thing to leave lying around.
Created attachment 227387 [details] [review] scanner: Correctly handle large 64 bit integer constants In C, positive integer constants are by default unsigned. This means an expression like 0x8000000000000000 will be "unsigned long long". In the actual scanner code, we were parsing them as "gint64", and storing them as gint64. This was incorrect; we need to parse them as guint64, and store the bits we get from that. This gives us an equivalent result to what the C compiler does. However, when we actually return the value as a Python "long" (arbitrary length integer), we need to treat the value as unsigned if the result indicated it was.
Comment on attachment 227387 [details] [review] scanner: Correctly handle large 64 bit integer constants Thanks Colin! I confirm that this fixes the .gir. Through pygobject it still comes out wrong, but that could just as well be a bug in pygobject itself; I'll take a closer look next week when I'll be back from UDS.
Attachment 227387 [details] pushed as 383b0bd - scanner: Correctly handle large 64 bit integer constants
Ah, I see the problem: The .gir is still wrong: <constant name="MAXUINT64" value="18446744073709551615" c:type="G_MAXUINT64"> <type name="gint64" c:type="gint64"/> </constant> That should be a data type of "guint64", just like MAXUINT{8,16,32} are unsigned types.
Created attachment 228296 [details] [review] scanner: Emit correct type for unsigned integer constants Otherwise bindings will break.
Comment on attachment 228296 [details] [review] scanner: Emit correct type for unsigned integer constants This looks good to me, and I confirm that this makes all things work in PyGObject without the workaround in the overrides. Thanks Colin!
Attachment 228296 [details] pushed as db71321 - scanner: Emit correct type for unsigned integer constants
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]