[Mono-bugs] [Bug 79312][Nor] Changed - returning a struct by value giving unexpected results

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Sep 7 14:31:57 EDT 2006


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by james.eberle at comcast.net.

http://bugzilla.ximian.com/show_bug.cgi?id=79312

--- shadow/79312	2006-09-07 05:20:36.000000000 -0400
+++ shadow/79312.tmp.15598	2006-09-07 14:31:57.000000000 -0400
@@ -77,6 +77,59 @@
   public static extern IntPtr GetCurrentEventLoop();
 
 
 Priority changed (see
 http://bugzilla.ximian.com/bug_status.html#priority).
 
+
+------- Additional Comments From james.eberle at comcast.net  2006-09-07 14:31 -------
+I simplified the problem as much as possible. Here is a more specific
+demonstration:
+
+using System;
+using System.Runtime.InteropServices;
+
+public enum EnumRef : uint {}
+
+public struct EventLoopRef {
+  public IntPtr h;
+}
+
+public struct HI {
+  public const string LIB =
+"/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/HIToolbox";
+
+  public static void Main() {
+    int          a = GetCurrentEventLoop1();
+    IntPtr       b = GetCurrentEventLoop2();
+    EnumRef      c = GetCurrentEventLoop3();
+    EventLoopRef d = GetCurrentEventLoop4();
+    Console.WriteLine("{0:x} {1:x} {2:x} {3:x}", a, (int)b, c, (int)d.h);
+  }
+
+  [DllImport(LIB, EntryPoint="GetCurrentEventLoop")]
+  public static extern int GetCurrentEventLoop1();
+
+  [DllImport(LIB, EntryPoint="GetCurrentEventLoop")]
+  public static extern IntPtr GetCurrentEventLoop2();
+
+  [DllImport(LIB, EntryPoint="GetCurrentEventLoop")]
+  public static extern EnumRef GetCurrentEventLoop3();
+
+  [DllImport(LIB, EntryPoint="GetCurrentEventLoop")]
+  public static extern EventLoopRef GetCurrentEventLoop4();
+
+}
+
+$ mcs -warn:4 -t:exe -out:q.exe q.cs
+$ mono q.exe
+7750915f 7750915f 7750915f e214c9f1 
+
+I realize it is common to use IntPtr for OS handles. I would really
+like to avoid that, since I'm wrapping many Carbon functions, and
+would like to maintain type safety. Currently, I'm just using enums
+(e.g. EnumRef), but that is tied to a given word size, so it's not
+32/64 bit friendly.
+
+Thanks for looking at this!
+Jim
+


More information about the mono-bugs mailing list