[Gtk-sharp-list] Cross Platform Assemblies?
16 Mar 2003 11:00:52 -0500
Actually, I am not aware of any 64-bit platform that has 64-bit ints.
ILP64 (where ints, longs, and pointers are 64-bits) has been rejected
(AFAIK) because it's wasteful of space. Most ints don't need to be
64-bits, so this would increase the size of most code for little
LP64 (where longs and pointers are 64-bits) makes more sense to lots of
There's also P64 (where only pointers are 64-bits, and 64-bit integers
get a new keyword, such as __int64 or "long long int"), which is what
Win64 is supposedly using, primarily because of backward compatibility
reasons (IIRC; much Windows code assumes that
So, for the int data type, this is likely not a problem. The use of
longs could introduce the problem (LP64 vs. P64), but I don't know if
(or how much) longs are used in Gtk+.
On Sun, 2003-03-16 at 02:53, Charles Iliya Krempeaux wrote:
> Looking at GLib's "gtypes.h", I see definitions like:
> typedef char gchar;
> typedef short gshort;
> typedef long glong;
> typedef int gint;
> typedef gint gboolean;
> typedef unsigned char guchar;
> typedef unsigned short gushort;
> typedef unsigned long gulong;
> typedef unsigned int guint;
> typedef float gfloat;
> typedef double gdouble;
> Now, what this means is that something like a "gint" is going to be a
> different size on different platforms. (On a x86 architecture it will
> be 32 bits wide. On something else it may be 64 bits wide.)
> Now, in the Gtk# code, we have DllImport statements all over the
> place that make assumptions about the size of these things.
> For instance, we have the C declaration:
> void gtk_widget_set_size_request (GtkWidget *widget,
> gint width,
> gint height);
> And in the Gtk#, this gets turned into:
> static extern
> void gtk_widget_set_size_request(IntPtr raw,
> int width,
> int height);
> Now, this says that a C# "int" is the same as a C "gint".
> Now, on a 32 bit architecture this is true. But, on a 64 bit
> architecture, this isn't!!!
> This is because, on a 64 bit architecture, a C "gint" will be
> 64 bits wide. But the .NET "int" will still be 32 bits wide
> (since it is an alias for "System.Int32".)
> Thus we seem to have a problem.
> This will likely require us to build 32 bit versions, 64 bit versions,
> and possible other size versions, of all our assemblies. (And maybe
> create stub .dll's that link to the correct one at runtime.)
> See ya