After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788132 - DynamicSignal: use NativeType property instead of doing unsafe pointer trickery
DynamicSignal: use NativeType property instead of doing unsafe pointer trickery
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-sharp
git master
Other Windows
: Normal normal
: 1.12.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-09-25 13:23 UTC by Erlend Graff
Modified: 2017-09-25 17:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch (1.29 KB, patch)
2017-09-25 13:23 UTC, Erlend Graff 		committed Details | Review

Description Erlend Graff 2017-09-25 13:23:15 UTC 
Created attachment 360354 [details] [review]
patch

The Microsoft C# (csc) compiler doesn't seem to like the "dereferencing"
of managed types very much (I'm using Microsoft (R) Visual C# Compiler version 2.3.2.62019 from VS 2017). It complains with error CS0208 "Cannot take the address of, get the size of, or declare a pointer to a managed type ('Object.GTypeInstance')".

Using the GLib.Object.NativeType property should return the same result.
However, this property actually has internal protection level, so glib-sharp must be compiled with an [assembly: InternalsVisibleTo("gstreamer-sharp")] directive for it to be accessible to gstreamer-sharp (when compiling with the MS C# compiler). But then again the types references in the previous unsafe-approach (GLib.Object.GTypeInstance etc.) also had internal visibility only.
Comment 1 Erlend Graff 2017-09-25 13:25:59 UTC 
If adding
 [assembly: InternalsVisibleTo("gstreamer-sharp")]
to glib-sharp's AssemblyInfo.cs is something that will be necessary in general when compiling gstreamer-sharp with the Microsoft C# compiler, is this maybe something we'd want to document? (Or is there maybe an easier way to achieve the same?)
Comment 2 Sebastian Dröge (slomo) 2017-09-25 13:35:58 UTC 
Review of attachment 360354 [details] [review]:

::: sources/custom/DynamicSignal.cs
@@ -335,3 @@
-				type = (*(IntPtr*) ((GLib.Object.GTypeInstance*) o.Handle)->g_class);
-			}
-			GType gtype = new GType (type);

Does o.NativeType also get the actual type from the instance, or only the type of the C# wrapper object (e.g. GstPlaybin2 is wrapped in a GstElement C# wrapper object, both having different GTypes and the latter not having all the GstPlaybin2 signals).