Any GstMessageType above GST_MESSAGE_EXTENDED not usable with python3 on windows

[Sebastian Dröge]

On Sat, 2017-08-26 at 21:18 +0000, philippe renon wrote:
> Hi,
> 
> The following python3 code:
> 
>     import gi
>     gi.require_version("Gst", "1.0")
>     from gi.repository import Gst
>     print(Gst.MessageType.get_name(Gst.MessageType.DEVICE_ADDED)) 
> 
> fails on windows 32 and 64 with this error:
> 
>     OverflowError: Python int too large to convert to C long
> 
>     The above exception was the direct cause of the following
> exception:
> 
>     Traceback (most recent call last):
>       File "bug.py", line 4, in <module>
>         print(Gst.MessageType.get_name(Gst.MessageType.DEVICE_ADDED))
>     SystemError: gi.FunctionInfo(get_name) returned a result with an
> error set
> 
> The same is true for any GstMessageType above or equal to
> GST_MESSAGE_EXTENDED.
> 
> My understanding of the issue is that, something, somewhere, is
> trying to map the Gst enum/flag to a C long.
> On Windows, according to [1], a long is a signed 32 bit integer
> (range is –2147483648 through 2147483647).
> But GST_MESSAGE_EXTENDED (and above enums) are too big to fit a
> Windows C long.
> GST_MESSAGE_EXTENDED = (1 << 31) = 2147483648 > 2147483647.
> 
> I found a somewhat similar issue : https://bugzilla.gnome.org/show_bu
> g.cgi?id=732633
> But this issue is related to signed vs unsigned (and is fixed in
> 1.12.2).
> 
> Is that issue fixable ? If yes, where should I look : pyobject,
> gobject-introspection, ... ?

Please file a bug about this. It's probably not fixable without changes
in the Python bindings (by using an unsigned int here instead of a
signed one) or ABI changes on the GStreamer side.

-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170828/cc7e01b9/attachment.sig>