GLib and 64-bit Windows

[Jake Goulding]

Hey all, i am trying to compile glib-2.8.6 (an older version, I know...) 
under Windows Server 2003 64-bit.

I hit the following issues:
gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier

This is caused by an if/else fallthrough in gbacktrace.h. Adding the 
following lines skipped that problem, but didn't fix it:

#elif defined (_MSC_VER) && defined (_M_X64)
#  define G_BREAKPOINT()G_STMT_START{ }G_STMT_EN

Then I immediately ran into other problems:
glib.def(129) : fatal error LNK1118: syntax error in 'G_GNUC_MALLOC' 
statement



My 2 questions:
Has GLib been successfully compiled in 64-bit mode under Windows?
Would a newer version of glib help me in getting my compile to work?

Thanks in advance!

-Jake
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

I'll wait to hear about the proper place to put these... but here are 
the mess of patches I currently apply against 2.12.9 to get something 
working under Windows 64-bit.


I tried to split all the patches into clearly-defined sections, but 
there is the chance that some overlap occurs. I simply apply all the 
patches, so I'm not sure if anything really depends on anything else.


Criticism is much appreciated (especially about the memory function 
signature changes)!


-Jake

diff -r --unified glib-2.12.9/glibconfig.h.win32 glib/glibconfig.h.win32
--- glib-2.12.9/glibconfig.h.win32  2007-01-16 18:50:49.0 -0500
+++ glib/glibconfig.h.win32 2007-04-13 17:41:09.68750 -0400
@@ -64,6 +64,17 @@
 #define G_GINT64_FORMAT "I64i"
 #define G_GUINT64_FORMAT "I64u"
 
+#if defined(_MSC_VER) && defined (_M_X64)
+#define GLIB_SIZEOF_VOID_P 8
+#define GLIB_SIZEOF_LONG   4
+#define GLIB_SIZEOF_SIZE_T 8
+
+typedef signed __int64 gssize;
+typedef unsigned __int64 gsize;
+#define G_GSIZE_MODIFIER "I64"
+#define G_GSSIZE_FORMAT "I64i"
+#define G_GSIZE_FORMAT "I64u"
+#else
 #define GLIB_SIZEOF_VOID_P 4
 #define GLIB_SIZEOF_LONG   4
 #define GLIB_SIZEOF_SIZE_T 4
@@ -73,14 +84,23 @@
 #define G_GSIZE_MODIFIER ""
 #define G_GSSIZE_FORMAT "i"
 #define G_GSIZE_FORMAT "u"
+#endif
 
 #define G_MAXSIZE  G_MAXUINT
 
+#if defined(_MSC_VER) && defined (_M_X64)
+#define GPOINTER_TO_INT(p) ((gint)  (long long) (p))
+#define GPOINTER_TO_UINT(p)((guint) (long long) (p))
+
+#define GINT_TO_POINTER(i) ((gpointer) (long long) (i))
+#define GUINT_TO_POINTER(u)((gpointer) (long long) (u))
+#else
 #define GPOINTER_TO_INT(p) ((gint)   (p))
 #define GPOINTER_TO_UINT(p)((guint)  (p))
 
 #define GINT_TO_POINTER(i) ((gpointer)  (i))
 #define GUINT_TO_POINTER(u)((gpointer)  (u))
+#endif
 
 #ifdef NeXT /* @[EMAIL PROTECTED] NeXTStep */
 # define g_ATEXIT(proc)(!atexit (proc))
diff -r --unified glib-2.12.9/glib/gbacktrace.h glib/glib/gbacktrace.h
--- glib-2.12.9/glib/gbacktrace.h   2007-01-16 18:24:35.0 -0500
+++ glib/glib/gbacktrace.h  2007-04-13 17:41:09.31250 -0400
@@ -50,6 +50,8 @@
 #  define G_BREAKPOINT()   G_STMT_START{ __asm__ __volatile__ ("int $03"); 
}G_STMT_END
 #elif defined (_MSC_VER) && defined (_M_IX86)
 #  define G_BREAKPOINT()   G_STMT_START{ __asm int 3h }G_STMT_END
+#elif defined (_MSC_VER) && defined (_M_X64)
+#  define G_BREAKPOINT()   G_STMT_START{}G_STMT_END
 #elif defined (__alpha__) && !defined(__osf__) && defined (__GNUC__) && 
__GNUC__ >= 2
 #  define G_BREAKPOINT()   G_STMT_START{ __asm__ __volatile__ ("bpt"); 
}G_STMT_END
 #else  /* !__i386__ && !__alpha__ */
diff -r --unified glib-2.12.9/glib/giowin32.c glib/glib/giowin32.c
--- glib-2.12.9/glib/giowin32.c 2007-01-16 18:24:35.0 -0500
+++ glib/glib/giowin32.c2007-04-13 17:41:09.37500 -0400
@@ -57,13 +57,13 @@
   G_IO_WIN32_FILE_DESC,/* Unix-like file descriptors from
 * _open() or _pipe(). Read with read().
 * Have to create separate thread to read.
-*/
+5~5~*/
   G_IO_WIN32_SOCKET/* Sockets. No separate thread */
 } GIOWin32ChannelType;
 
 struct _GIOWin32Channel {
   GIOChannel channel;
-  gint fd; /* Either a Unix-like file handle as provided
+  gint64 fd;   /* Either a Unix-like file handle as provided
 * by the Microsoft C runtime, or a SOCKET
 * as provided by WinSock.
 */
@@ -112,7 +112,7 @@
   /* Following fields used by socket channels */
   int event_mask;
   int last_events;
-  int event;
+  gpointer event;
   gboolean write_would_have_blocked;
 };
 
@@ -390,11 +390,11 @@
   g_io_channel_ref ((GIOChannel *)channel);
 
   if (channel->debug)
-g_print ("read_thread %#x: start fd=%d, data_avail=%#x space_avail=%#x\n",
+g_print ("read_thread %#x: start fd=%d, data_avail=%p space_avail=%p\n",
 channel->thread_id,
 channel->fd,
-(guint) channel->data_avail_event,
-(guint) channel->space_avail_event);
+channel->data_avail_event,
+channel->space_avail_event);
 
   channel->direction = 0;
   channel->buffer = g_malloc (BUFFER_SIZE);
@@ -501,11 +501,11 @@
   g_io_channel_ref ((GIOChannel *)channel);
 
   if (channel->debug)
-g_print ("write_thread %#x: start fd=%d, data_avail=%#x space_avail=%#x\n",
+g_print ("write_thread %#x: start fd=%d, data_avail=%p space_avail=%p\n",
 channel->thread_id,
 channel->fd,
-(guint) channel->data_avail_event,
-(guint) channel->space_avail_event);
+channel->data_avail_event,
+channel->space_avail_event);
   
   channel->direction = 1;
   channel->buffer = g_malloc (BUFFER_SIZE);
@@ -924,6 +92

Re: GLib and 64-bit Windows

[Tor Lillqvist]

Jake Goulding writes:
Some comments inline below:

 > +#if defined(_MSC_VER) && defined (_M_X64)

It would be better to separate things that are compiler-dependent and
things that are platform dependent. If and when gcc becomes available
for 64-bit Windows, _MSC_VER won't be defined when using it.

Also, the current mingw (gcc for x86) seems to not predefine _M_IX86,
that gets defined only if one includes . Thus I would
assume a gcc for 64-bit Windows will do the same. Testing for _WIN64
is probably a better choice than _M_X64.

So, for 64-bit Windows in general, using #ifdef _WIN64 is probably
better. Then, use _MSC_VER to differentiate between MSVC and others.

 > +typedef signed __int64 gssize;
 > +typedef unsigned __int64 gsize;

These are MSVC-specific, for gcc we can presumably use signed/unsigned
long long.

 >  struct _GPollFD
 >  {
 > -  gint  fd;
 > +//  gintfd;
 > +  gpointer  fd;

We can't change GPollFD::fd to a gpointer, that would break user
code. This is already changed in trunk as follows:

struct _GPollFD
{
#if defined (G_OS_WIN32) && GLIB_SIZEOF_VOID_P == 8
  gint64fd;
#else
  gint  fd;
#endif
...

 >  g_date_set_time (GDate*date,
 > - GTime*time_)
 > + GTimetime_)

Already fixed in trunk and glib-2-12.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Olivier Chertier]

> Hey all, i am trying to compile glib-2.8.6 (an older version, I know...)
under Windows Server 2003 64-bit.
> I hit the following issues:
> gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier
>
> This is caused by an if/else fallthrough in gbacktrace.h. Adding the
following lines skipped that problem, but didn't fix it:
> #elif defined (_MSC_VER) && defined (_M_X64)
> #  define G_BREAKPOINT()G_STMT_START{ }G_STMT_EN
>
> Then I immediately ran into other problems:
> glib.def(129) : fatal error LNK1118: syntax error in 'G_GNUC_MALLOC'
statement
>
>
> My 2 questions:
> Has GLib been successfully compiled in 64-bit mode under Windows?
> Would a newer version of glib help me in getting my compile to work?
>
> Thanks in advance!
>
> -Jake

Hi Jake,

Did you success to compil your glib-2.8.6 version, because me I am trying
to compil glib2.4.0 on WIndows 64-bits.

If you have some stable predefined  glib/*.h  that I could use to fix my
trouble it could be greatfull.
And also if you have some details to well compiled under windows 64 (are
you using MINGW/MSYS or VISUAL2005 ?)

Thanks

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Yevgen Muntyan]

Tim Janik wrote:
> On Mon, 5 Mar 2007, Owen Taylor wrote:
>
>   
>> On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:
>> 
>
>   
>>> goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to
>>> 'gulong', possible loss of data
>>> change->allocated.array.data = g_renew (gchar *,
>>> change->allocated.array.data, change->allocated.array.len + 2);
>>>
>>> And more. It sure looks like most of them have to do with the allocation
>>> functions, which all seem to take ulongs as opposed to size_t.
>>>   
>> Hmm. I think in terms of gmem.h we probably should try to fix the
>> ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
>> don't have to worry about a binary compatibility issue with changing the
>> prototype. And on all other platforms I know of gsize and ulong are the
>> same size.
>> 
>
> agree. this exact API was actually written with sizeof(long)==8 on 64-bit
> platforms in mind:
>
> 2008-01-29 14:58:31  Tim Janik  <[EMAIL PROTECTED]>
>
>  * glib/gmem.[hc]: changed size argument type from gulong to gsize as
>  discussed on gtk-devel-list:
>
> http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html
>  this should be ABI compatible on all platforms except win64 for which
>  no ABI binding port exists yet.
>
>   
>> There *are* platforms where gssize is an unsigned integer rather than an
>> unsigned long, but my general feeling is that just changing the gmalloc
>> prototypes is unlikely to cause problems; GMemVTable, which would be
>> more likely to cause warnings already has gsize there.
>> 
>
> i suppose you mean gsize (which is always unsigned), because gssize is
> always signed.
>
>   
>> There are going to be other situations however, where the fix isn't so
>> obvious.
>>
>> - When 64-bit proofing the Unicode string bits of GLib (years ago)
>>   I took the policy that:
>>
>>- Counts of bytes were sized as gsize
>>- Counts of "items" sized larger than a byte are longs
>>
>>   because it seemed very strange to me to use size_t for non-byte
>>   counts.
>> 
>
> C++ does this all the time though (also calls it's .get_number_of_elements()
> methods .size()), so you get used to it after a bit of STL fiddling.
>
>   
>>   But that means that something like the return value from
>>   g_utf8_strlen() is wrong for win32. This can't be changed in a
>>   source-compatible fashion.
>>
>>   Probably the right thing to do for g_utf8_strlen() is to compute
>>   things internally as 64-bit, then clamp the result to 32-bits
>>   on return. Without the clamp:
>>
>> long size = g_utf8_strlen(str);
>> gunichar chars = g_new(gunichar, size);
>> for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
>>*c = g_utf8_get_char(p);
>> }
>>
>>Is a potential buffer overflow, though a hard one to trigger.
>>(Actually, it's a potential overflow currently for 32-bits. We really
>>should make g_new0() not a g_malloc()-wrapping macro so we can protect
>>the multiplication.)
>> 
>
> if i understand you correctly, you mean to imply that we also fix the
> signatures from *long to *size as well for the following functions
> (comprehensive list of *long API in glib/glib/*.h):
>
>
> gdouble  g_timer_elapsed (GTimer  *timer,
>gulong  *microseconds);
> void g_usleep(gulong   microseconds);
> void g_time_val_add  (GTimeVal*time_,
>glongmicroseconds);
>   

It'd be weird to have gsize here. And, if 32 bits are
not enough (for actual time intervals possible there),
then it should be guint64 on all platforms. If 32 bits are
enough, then gulong is fine as it is.

> gboolean g_hook_destroy (GHookList  *hook_list,
>   gulong  hook_id);
> GHook*   g_hook_get (GHookList  *hook_list,
>   gulong  hook_id);
>   

And here.

For "sizes" and "lengths", gsize would be pretty nice. Say,
C library uses size_t everywhere (well, it's not a consistency
champion either of course).

Best regards,
Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tim Janik]

On Mon, 5 Mar 2007, Owen Taylor wrote:

> On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:

>> goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to
>> 'gulong', possible loss of data
>> change->allocated.array.data = g_renew (gchar *,
>> change->allocated.array.data, change->allocated.array.len + 2);
>>
>> And more. It sure looks like most of them have to do with the allocation
>> functions, which all seem to take ulongs as opposed to size_t.
>
> Hmm. I think in terms of gmem.h we probably should try to fix the
> ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
> don't have to worry about a binary compatibility issue with changing the
> prototype. And on all other platforms I know of gsize and ulong are the
> same size.

agree. this exact API was actually written with sizeof(long)==8 on 64-bit
platforms in mind:

2008-01-29 14:58:31  Tim Janik  <[EMAIL PROTECTED]>

 * glib/gmem.[hc]: changed size argument type from gulong to gsize as
 discussed on gtk-devel-list:
   
http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html
 this should be ABI compatible on all platforms except win64 for which
 no ABI binding port exists yet.

> There *are* platforms where gssize is an unsigned integer rather than an
> unsigned long, but my general feeling is that just changing the gmalloc
> prototypes is unlikely to cause problems; GMemVTable, which would be
> more likely to cause warnings already has gsize there.

i suppose you mean gsize (which is always unsigned), because gssize is
always signed.

> There are going to be other situations however, where the fix isn't so
> obvious.
>
> - When 64-bit proofing the Unicode string bits of GLib (years ago)
>   I took the policy that:
>
>- Counts of bytes were sized as gsize
>- Counts of "items" sized larger than a byte are longs
>
>   because it seemed very strange to me to use size_t for non-byte
>   counts.

C++ does this all the time though (also calls it's .get_number_of_elements()
methods .size()), so you get used to it after a bit of STL fiddling.

>   But that means that something like the return value from
>   g_utf8_strlen() is wrong for win32. This can't be changed in a
>   source-compatible fashion.
>
>   Probably the right thing to do for g_utf8_strlen() is to compute
>   things internally as 64-bit, then clamp the result to 32-bits
>   on return. Without the clamp:
>
> long size = g_utf8_strlen(str);
> gunichar chars = g_new(gunichar, size);
> for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
> *c = g_utf8_get_char(p);
> }
>
>Is a potential buffer overflow, though a hard one to trigger.
>(Actually, it's a potential overflow currently for 32-bits. We really
>should make g_new0() not a g_malloc()-wrapping macro so we can protect
>the multiplication.)

if i understand you correctly, you mean to imply that we also fix the
signatures from *long to *size as well for the following functions
(comprehensive list of *long API in glib/glib/*.h):


gdouble  g_timer_elapsed (GTimer  *timer,
   gulong  *microseconds);
void g_usleep(gulong   microseconds);
void g_time_val_add  (GTimeVal*time_,
   glongmicroseconds);
gchar*   g_utf8_offset_to_pointer (const gchar *str,
glongoffset) G_GNUC_PURE;
glongg_utf8_pointer_to_offset (const gchar *str,
const gchar *pos) G_GNUC_PURE;
glong g_utf8_strlen (const gchar *p,
  gssize   max) G_GNUC_PURE;
gunichar2 *g_utf8_to_utf16 (const gchar  *str,
 glong len,
 glong*items_read,
 glong*items_written,
 GError  **error) G_GNUC_MALLOC;
gunichar * g_utf8_to_ucs4  (const gchar  *str,
 glong len,
 glong*items_read,
 glong*items_written,
 GError  **error) G_GNUC_MALLOC;
gunichar * g_utf8_to_ucs4_fast (const gchar  *str,
 glong len,
 glong*items_written) 
G_GNUC_MALLOC; 
gunichar * g_utf16_to_ucs4 (const gunichar2  *str,
 glong len,
 glong*items_read,
 glong*items_written,
 GError  **error) G_GNUC_MALLOC;
gchar* g_utf16_to_utf8 (const gunichar2  *str,
 glong len,

Re: GLib and 64-bit Windows

[Tor Lillqvist]

> does struct timeval use 32 or 64 bit fields on win64?

Is uses "long", so 32 bits.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Owen Taylor]

On Tue, 2008-01-29 at 15:12 +0100, Tim Janik wrote:

> 2008-01-29 14:58:31  Tim Janik  <[EMAIL PROTECTED]>
> 
>  * glib/gmem.[hc]: changed size argument type from gulong to gsize as
>  discussed on gtk-devel-list:
>
> http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html
>  this should be ABI compatible on all platforms except win64 for which
>  no ABI binding port exists yet.
> 
> > There *are* platforms where gssize is an unsigned integer rather than an
> > unsigned long, but my general feeling is that just changing the gmalloc
> > prototypes is unlikely to cause problems; GMemVTable, which would be

So, changing the gmem.h prototypes actually broke compilation of
gnome-keyring. (It was passing g_realloc into a function that took a
function pointer; causing a warning, and with -Werror on, a fatal
error.)

My feeling is that this is *probably* OK (in the context of a
between-major-version releases), though if more problem start showing
up, changing the prototypes only for Win64 might be necessary.

> > more likely to cause warnings already has gsize there.
> 
> i suppose you mean gsize (which is always unsigned), because gssize is
> always signed.

I'm not sure what you you are asking here. What I was saying is that 
changing vtable members is more likely to break things than changing
function prototypes.

> > There are going to be other situations however, where the fix isn't so
> > obvious.
> >
> > - When 64-bit proofing the Unicode string bits of GLib (years ago)
> >   I took the policy that:
> >
> >- Counts of bytes were sized as gsize
> >- Counts of "items" sized larger than a byte are longs
> >
> >   because it seemed very strange to me to use size_t for non-byte
> >   counts.
> 
> C++ does this all the time though (also calls it's .get_number_of_elements()
> methods .size()), so you get used to it after a bit of STL fiddling.
> 
> >   But that means that something like the return value from
> >   g_utf8_strlen() is wrong for win32. This can't be changed in a
> >   source-compatible fashion.
> >
> >   Probably the right thing to do for g_utf8_strlen() is to compute
> >   things internally as 64-bit, then clamp the result to 32-bits
> >   on return. Without the clamp:
> >
> > long size = g_utf8_strlen(str);
> > gunichar chars = g_new(gunichar, size);
> > for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
> >   *c = g_utf8_get_char(p);
> > }
> >
> >Is a potential buffer overflow, though a hard one to trigger.
> >(Actually, it's a potential overflow currently for 32-bits. We really
> >should make g_new0() not a g_malloc()-wrapping macro so we can protect
> >the multiplication.)
> 
> if i understand you correctly, you mean to imply that we also fix the
> signatures from *long to *size as well for the following functions
> (comprehensive list of *long API in glib/glib/*.h):
> 
> 
> gdouble  g_timer_elapsed (GTimer  *timer,
>gulong  *microseconds);
[...]

No, I didn't mean that, because 

 
 gdouble  g_timer_elapsed (GTimer  *timer,
   size_t  *microseconds);

 gulong microseconds;

 g_timer_elapsed(timer, µseconds);

Will warn in many many situations on many platforms, and MSVC will warn
about:

 gsize g_utf8_strlen (const gchar *p,  
  gssize   max);

 long value = g_utf8_strlen(p, max);

even when compiling for 32 bits. So I don't consider changing out
parameters and returns from long => size_t compatible.

- Owen



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Hans Breuer]

On 01.03.2007 21:40, Jake Goulding wrote:
> Hey all, i am trying to compile glib-2.8.6 (an older version, I know...) 
> under Windows Server 2003 64-bit.
> 
> I hit the following issues:
> gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier
> 
> This is caused by an if/else fallthrough in gbacktrace.h. Adding the 
> following lines skipped that problem, but didn't fix it:
> 
> #elif defined (_MSC_VER) && defined (_M_X64)
> #  define G_BREAKPOINT()G_STMT_START{ }G_STMT_EN
> 
> Then I immediately ran into other problems:
> glib.def(129) : fatal error LNK1118: syntax error in 'G_GNUC_MALLOC' 
> statement
> 
> 
> 
> My 2 questions:
> Has GLib been successfully compiled in 64-bit mode under Windows?
Didn't hear about that.

> Would a newer version of glib help me in getting my compile to work?
> 
Yes. At least the above mentioned issue is fixed on trunk. But there are
probably more things to fix, which could be merged to trunk but much less
to glib-2-8.

gobject.def: gobject.symbols
echo EXPORTS > gobject.def
cl /EP -DINCLUDE_VARIABLES -DG_OS_WIN32 -DALL_FILES \
-DG_GNUC_MALLOC= -DG_GNUC_CONST= -DG_GNUC_NULL_TERMINATED=
-DG_GNUC_NORETURN= \
-DG_GNUC_PRINTF=;G_GNUC_PRINTF gobject.symbols >> gobject.def


Hans

 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Thanks for the prompt response Hans.

>> Has GLib been successfully compiled in 64-bit mode under Windows?
>> 
> Didn't hear about that.
>
>   
Do you have a rough idea of the amount of work that it would take to get 
this working? I don't mind doing the work, but I'm not entirely familiar 
with glib. What parts of glib touch (possibly) 64-bit specific code?

>> Would a newer version of glib help me in getting my compile to work?
>> 
> Yes. At least the above mentioned issue is fixed on trunk. But there are
> probably more things to fix, which could be merged to trunk but much less
> to glib-2-8.
>
>   
Maybe I am just being dense here, but am I right in interpreting this to 
mean: if I fix things to get a 64-bit build, those fixes could more 
easily be merged back into the trunk, where as they would be less likely 
to make it into 2.8?


-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

Jake Goulding writes:
 > Hey all, i am trying to compile glib-2.8.6 (an older version, I know...) 
 > under Windows Server 2003 64-bit.

I certainly am interested in hearing about GLib on 64-bit Windows, but
I don't bother to keep the sources to such old versions on my disk any
longer. I don't see what the point is in trying to build that. If you
want to get any needed patches upstream, they should be for the trunk,
and possibly also the stable branch (glib-2-12) anyway.

 > Then I immediately ran into other problems:
 > glib.def(129) : fatal error LNK1118: syntax error in 'G_GNUC_MALLOC' 
 > statement

You will have to manually edit out the G_GNUC_ stuff from glib.def. It
is supposed to be passed through the C preprocessor and have those
expanded to empty. This is handled properly in trunk's
glib/makefile.msc(.in).

 > Has GLib been successfully compiled in 64-bit mode under Windows?

Nobody has reported it here anyway.

 > Would a newer version of glib help me in getting my compile to work?

See above, it would at least for the glib.def problem. And there is no
mention of SIGTRAP in gbacktrace.c in newer GLibs, so presumably that
would also not be a problem.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

 > if I fix things to get a 64-bit build, those fixes could more 
 > easily be merged back into the trunk, where as they would be less likely 
 > to make it into 2.8?

Exactly. 2.8 isn't maintained any more, there won't be any more
releases of it, so there is no point in putting things into the 2.8
branch. We have already moved two release cycles forward, 2.12 is the
stable branch now.

(Well, of course, if somebody *wanted*, they could of course "fork"
GLib 2.8, patch and enhance it, and do their own source and binary
releases of it. That's one of the freedom's that the LGPL license
gives you. But I don't see any point in it, at least not for the
purpose of porting GLib to win64.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

I think I have made some progress...  at least the following libraries 
have been built:

./build/win32/dirent/dirent.lib
./glib/glib-2.0.lib
./glib/glib-2.12s.lib
./glib/gnulib/gnulib.lib
./gmodule/gmodule-2.0.lib
./gobject/gobject-2.0.lib
./gobject/gobject-2.12s.lib
./gthread/gthread-2.0.lib

Is running each of the test executables in the tests directory and 
getting a 0 exit code for each a reasonable sanity check that everything 
compiled correctly and is working?

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

 > I think I have made some progress...  at least the following libraries=20
 > have been built:

 > build/win32/dirent/dirent.lib
 > glib/gnulib/gnulib.lib

(These are just auxiliary libraries that are linked in the glib DLL.)

 > glib/glib-2.0.lib
 > gmodule/gmodule-2.0.lib
 > gobject/gobject-2.0.lib
 > gthread/gthread-2.0.lib

Hopefully these are just import libraries, and you got DLLs, too?

BTW, did you build the external libraries GLib depends on,
gettext-runtime (usually with an import library called "intl.lib") and
libiconv ("iconv.lib"), too, or did you find them somewhere prebuilt
for Win64?

 > glib/glib-2.12s.lib
 > object/gobject-2.12s.lib

These are static libraries. When building GLib for Win32 with gcc no
static libraries are produced, but the MSVC makefiles build such, too,
for some reason.

 > Is running each of the test executables in the tests directory and=20
 > getting a 0 exit code for each a reasonable sanity check that everything=20
 > compiled correctly and is working?

Good!

The tests don't necessarily test everything, but this does indeed
sound promising. Are you then going to proceed to build atk, Pango and
GTK+?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

>  > I think I have made some progress...  at least the following libraries
>  > have been built:
>
>  > build/win32/dirent/dirent.lib
>  > glib/gnulib/gnulib.lib
>
> (These are just auxiliary libraries that are linked in the glib DLL.)
>   
Right, but are nonetheless needed for the rest of glib. :-D

>  > glib/glib-2.0.lib
>  > gmodule/gmodule-2.0.lib
>  > gobject/gobject-2.0.lib
>  > gthread/gthread-2.0.lib
>
> Hopefully these are just import libraries, and you got DLLs, too?
>
>   
Apologies for forgetting that...

./glib/libglib-2.0-0.dll
./gmodule/libgmodule-2.0-0.dll
./gobject/libgobject-2.0-0.dll
./gthread/libgthread-2.0-0.dll

> BTW, did you build the external libraries GLib depends on,
> gettext-runtime (usually with an import library called "intl.lib") and
> libiconv ("iconv.lib"), too, or did you find them somewhere prebuilt
> for Win64?
>
>   
I built these from scratch as well. They required very minor changes, if 
I remember correctly at this point.

>  > glib/glib-2.12s.lib
>  > object/gobject-2.12s.lib
>
> These are static libraries. When building GLib for Win32 with gcc no
> static libraries are produced, but the MSVC makefiles build such, too,
> for some reason.
>   
Unfortunately, our particular use of glib requires static libraries for 
everything (we static link on all the platforms our software is shipped 
on, to minimize runtime issues). I asked this on the list at some point 
in the past, and I think these are static libraries are (were?) for some 
type of bootstrapping during the build. I had to hack up the 2.8.6 build 
to get static libraries out of it.

>  > Is running each of the test executables in the tests directory and
>  > getting a 0 exit code for each a reasonable sanity check that everything
>  > compiled correctly and is working?
>
> Good!
>
> The tests don't necessarily test everything, but this does indeed
> sound promising.
>   
Well, I didn't say that I *did* run them and get good outputs, I just 
wanted to make sure that was what the expected behavior was. :-)
However, I have run the majority of them. Unfortunately there are a few 
that require inputs and I am clueless as to what they need to run.
Most have passed, but spawn-test seems to freak out on me. I am checking 
to see if I can figure that out.

There are whole piles of warnings about signed/unsigned comparisons and 
type size issues:

warning C4311: 'type cast' : pointer truncation from 'gpointer' to 'long'
warning C4018: '<' : signed/unsigned mismatch
warning C4267: 'function' : conversion from 'size_t' to 'gssize', 
possible loss of data
warning C4090: 'initializing' : different 'const' qualifiers

I'm not sure which warnings are ignorable, and which are not. 
Personally, I'm quite pedantic about my own code, and like to fix 
everything, but I know that's not always feasible.

>  Are you then going to proceed to build atk, Pango and GTK+?
>   
Unfortunately, my company only uses glib as a platform compatibility 
library. We don't have any use for atk, Pango, or GTK+ in our product. 
We use a few tools later on that rely on glib, but none of the fancy 
libraries.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Hans Breuer]

On 02.03.2007 22:49, Jake Goulding wrote:
>On 02.03.2007 22:29, Tor Lillqvist wrote:
>> The tests don't necessarily test everything, but this does indeed
>> sound promising.
>>   
> Well, I didn't say that I *did* run them and get good outputs, I just 
> wanted to make sure that was what the expected behavior was. :-)
> However, I have run the majority of them. Unfortunately there are a few 
> that require inputs and I am clueless as to what they need to run.
> Most have passed, but spawn-test seems to freak out on me. I am checking 
> to see if I can figure that out.
> 
There may be trouble with the process id passed between lib and
spawn-helper. The GPid definition was added with win64 in mind but not
tested at that time. It probably needs to be an int64 there.

> There are whole piles of warnings about signed/unsigned comparisons and 
> type size issues:
> 
> warning C4311: 'type cast' : pointer truncation from 'gpointer' to 'long'
You should probably look at these.

> warning C4018: '<' : signed/unsigned mismatch
these are not win64 specific and probably harmless

> warning C4267: 'function' : conversion from 'size_t' to 'gssize', 
> possible loss of data
Sounds like a bug in your configuration. IIRC gssize should match the size
of size_t, both 64 bits in this case.

> warning C4090: 'initializing' : different 'const' qualifiers
> 
could be ignored unless there is something supicious in its area.

> I'm not sure which warnings are ignorable, and which are not. 
> Personally, I'm quite pedantic about my own code, and like to fix 
> everything, but I know that's not always feasible.
> 
I think a series of patches to fix these warnings would be gladly accepted.


Hans

 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

Hans Breuer writes:
 > I think a series of patches to fix these warnings would be gladly accepted.

Unless we are still talking about GLib 2.8.6 here, in which case
patches are useful only if the same problem still exists in trunk or
2.12.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Ah, I guess I forgot to mention my attack plan here...

I am working off of the latest stable version (2.12.9) as we will  
want the most stable for our product. I figure that I can apply most  
(if not all) of the changes to the trunk. After I get the stable  
version, I'll probably give a swing at the trunk to see how it shapes  
up, but here at work we will stay with the stable for now.


On Mar 2, 2007, at 7:37 PM, Tor Lillqvist wrote:

> Hans Breuer writes:
>> I think a series of patches to fix these warnings would be gladly  
>> accepted.
>
> Unless we are still talking about GLib 2.8.6 here, in which case
> patches are useful only if the same problem still exists in trunk or
> 2.12.
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Here is the full list of warnings from the glib directory. Please let me 
know if you agree with my sorting into two groups.

Needs to be fixed:
warning C4028: formal parameter 2 different from declaration
warning C4113: 'GCond *(__cdecl *)()' differs in parameter lists from 
'GCond *(__cdecl *)(void)'
warning C4113: 'GMutex *(__cdecl *)()' differs in parameter lists from 
'GMutex *(__cdecl *)(void)'
warning C4133: 'function' : incompatible types - from 'glong *' to 
'const time_t *'
warning C4146: unary minus operator applied to unsigned type, result 
still unsigned
warning C4267: '=' : conversion from 'size_t' to 'gint', possible loss 
of data
warning C4267: '=' : conversion from 'size_t' to 'glong', possible loss 
of data
warning C4267: '=' : conversion from 'size_t' to 'guint', possible loss 
of data
warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of 
data
warning C4267: 'function' : conversion from 'size_t' to 'guint', 
possible loss of data
warning C4267: 'function' : conversion from 'size_t' to 'gulong', 
possible loss of data
warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', 
possible loss of data
warning C4267: 'initializing' : conversion from 'size_t' to 'const 
gint', possible loss of data
warning C4267: 'initializing' : conversion from 'size_t' to 'gint', 
possible loss of data
warning C4311: 'type cast' : pointer truncation from 'ChunkLink *' to 
'guint'
warning C4311: 'type cast' : pointer truncation from 'GPid' to 'int'
warning C4311: 'type cast' : pointer truncation from 'HANDLE' to 'gint'
warning C4311: 'type cast' : pointer truncation from 'HANDLE' to 'guint'
warning C4311: 'type cast' : pointer truncation from 'HANDLE' to 'int'
warning C4311: 'type cast' : pointer truncation from 'HWND' to 'guint'
warning C4311: 'type cast' : pointer truncation from 'const void *' to 
'guint'
warning C4311: 'type cast' : pointer truncation from 'gconstpointer' to 
'guint'
warning C4311: 'type cast' : pointer truncation from 'gpointer' to 'guint'
warning C4311: 'type cast' : pointer truncation from 'gpointer' to 'gulong'
warning C4311: 'type cast' : pointer truncation from 'guint8 *' to 'glong'
warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 
bits (was 64-bit shift intended?)
warning C4715: 'g_io_win32_check' : not all control paths return a value

Doesn't need to be fixed(?):
warning C4005: 'min' : macro redefinition
warning C4018: '<' : signed/unsigned mismatch
warning C4018: '<=' : signed/unsigned mismatch
warning C4018: '>' : signed/unsigned mismatch
warning C4018: '>=' : signed/unsigned mismatch
warning C4090: 'function' : different 'const' qualifiers
warning C4312: 'type cast' : conversion from 'GQuark' to 'gpointer' of 
greater size
warning C4312: 'type cast' : conversion from 'gint' to 'HANDLE' of 
greater size
warning C4312: 'type cast' : conversion from 'guint' to 'HWND' of 
greater size
warning C4312: 'type cast' : conversion from 'guint' to 'gpointer' of 
greater size
warning C4312: 'type cast' : conversion from 'gunichar' to 'gpointer' of 
greater size
warning C4312: 'type cast' : conversion from 'int' to 'GPid' of greater size
warning C4312: 'type cast' : conversion from 'int' to 'HANDLE' of 
greater size

Hans Breuer wrote:
> On 02.03.2007 22:49, Jake Goulding wrote:
>   
>> On 02.03.2007 22:29, Tor Lillqvist wrote:
>> 
>>> The tests don't necessarily test everything, but this does indeed
>>> sound promising.
>>>   
>>>   
>> Well, I didn't say that I *did* run them and get good outputs, I just 
>> wanted to make sure that was what the expected behavior was. :-)
>> However, I have run the majority of them. Unfortunately there are a few 
>> that require inputs and I am clueless as to what they need to run.
>> Most have passed, but spawn-test seems to freak out on me. I am checking 
>> to see if I can figure that out.
>>
>> 
> There may be trouble with the process id passed between lib and
> spawn-helper. The GPid definition was added with win64 in mind but not
> tested at that time. It probably needs to be an int64 there.
>
>   
>> There are whole piles of warnings about signed/unsigned comparisons and 
>> type size issues:
>>
>> warning C4311: 'type cast' : pointer truncation from 'gpointer' to 'long'
>> 
> You should probably look at these.
>
>   
>> warning C4018: '<' : signed/unsigned mismatch
>> 
> these are not win64 specific and probably harmless
>
>   
>> warning C4267: 'function' : conversion from 'size_t' to 'gssize', 
>> possible loss of data
>> 
> Sounds like a bug in your configuration. IIRC gssize should match the size
> of size_t, both 64 bits in this case.
>
>   
>> warning C4090: 'initializing' : different 'const' qualifiers
>>
>> 
> could be ignored unless there is something supicious in its area.
>
>   
>> I'm not sure which warnings are ignorable, and which are not. 
>> Personally, I'm quite pedantic about my own code, and like to fix 
>> everything, but I know that's not alway

Re: GLib and 64-bit Windows

[Hubert Figuiere]

Jake Goulding wrote:
> Unfortunately, our particular use of glib requires static libraries for 
> everything (we static link on all the platforms our software is shipped 
> on, to minimize runtime issues). I asked this on the list at some point 
> in the past, and I think these are static libraries are (were?) for some 
> type of bootstrapping during the build. I had to hack up the 2.8.6 build 
> to get static libraries out of it.

Side note:

Remember that Glib is LGPL. That means if your product is not open
source, it has to provide a way for your customers to relink against
their own version of Glib is they want. Static linking make this just a
bit harder.


Hub
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

You wouldn't have the file names and line numbers for those
warnings...? (Maybe you could put the whole compilation output
listing up on the web somewhere.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Of course, that would have made more sense... :-)

http://www.myxopho.be/glib-win64-compile.log
And grepped for warning:
http://www.myxopho.be/glib-win64-warnings.log


Tor Lillqvist wrote:
> You wouldn't have the file names and line numbers for those
> warnings...? (Maybe you could put the whole compilation output
> listing up on the web somewhere.)
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>   

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

I think a large amount of errors stem from the fact that it is assumed 
that sizeof(long) == sizeof(void *)

Both from a 64-bit AMD machine...
Linux:
char: 1
short: 2
int: 4
long: 8
long long: 8
void *: 8
size_t: 8

Win64:
char: 1
short: 2
int: 4
long: 4
long long: 8
void *: 8
HANDLE: 8
size_t: 8

This would certainly explain all sorts of the warnings (not all, of course).


Jake Goulding wrote:
> Of course, that would have made more sense... :-)
>
> http://www.myxopho.be/glib-win64-compile.log
> And grepped for warning:
> http://www.myxopho.be/glib-win64-warnings.log
>
>
> Tor Lillqvist wrote:
>   
>> You wouldn't have the file names and line numbers for those
>> warnings...? (Maybe you could put the whole compilation output
>> listing up on the web somewhere.)
>>
>> --tml
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>>   
>> 
>
>   

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Also that sizeof(long) == sizeof(size_t)

Looking at the API reference for g[u]long 
(http://developer.gnome.org/doc/API/2.0/glib/glib-Basic-Types.html)...
"Corresponds to the standard C [unsigned] long type"

It certainly makes horse-sense that long would be a 64-bit on a 64-bit 
platform, but I know the standard doesn't guarantee it. GCC on linux has 
a long as 64-bits. As far as I can tell, there is no 64-bit GCC for 
Windows (yet?) to compare against.

How *wrong* would it be to define g[u]long as forcibly 64-bit on a 
64-bit platform?

Jake Goulding wrote:
> I think a large amount of errors stem from the fact that it is assumed 
> that sizeof(long) == sizeof(void *)
>   

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Morten Welinder]

> I think a large amount of errors stem from the fact that it is assumed
> that sizeof(long) == sizeof(void *)

">=", I think, but yes.  You need to make sure configure defines gsize
as unsigned
long long, and gssize as long long.

You might also want to check...

* the ptrdiff_t type.  If it has a different size that size_t, there
might be a bit of
  fun hidden there too.

* if NULL is an integer type.  No, really.  If it is defined as just
"0" or "0L", you are
  in for a world of hurt.  It should be simplest to override the
definition in that case.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Morten Welinder wrote:
> ">=", I think, but yes.  You need to make sure configure defines gsize
> as unsigned
> long long, and gssize as long long.
>
Well, gsize is actually fine. There is a "native" size_t type that is 8 
bytes. long is the issue here, as it is only 4 bytes. long long is 8 
bytes, as you suggested.

> You might also want to check...
>
> * the ptrdiff_t type.  If it has a different size that size_t, there
> might be a bit of  fun hidden there too.
>
Thankfully, this is fine. sizeof(ptrdiff_t) == 8.

> * if NULL is an integer type.  No, really.  If it is defined as just
> "0" or "0L", you are in for a world of hurt. 
> It should be simplest to override the definition in that case.
I'm not even sure where or how I could check for this. Any clues?

Thanks for the tips!

-Jake
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[muppet]

On Mar 3, 2007, at 5:02 PM, Jake Goulding wrote:

> Morten Welinder wrote:
>> * if NULL is an integer type.  No, really.  If it is defined as just
>> "0" or "0L", you are in for a world of hurt.
>> It should be simplest to override the definition in that case.
> I'm not even sure where or how I could check for this. Any clues?

Use the preprocessor to expand it for you:

$ gcc -E - < #include  /* NULL is defined somewhere in here */
 > void *p = NULL;
 > EOF
void *p = ((void *)0);




--
Doing a good job around here is like wetting your pants in a dark  
suit; you get a warm feeling, but no one notices.
   -- unknown


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Duh... of course. I always forget about -E (which is conveniently the 
same for MSVCs cl.exe)

So, yeah, it is 0 cast to a void *. I figured it would be good, as most 
of the tests ran fine, but always good to double check. :-D


muppet wrote:
>
> Use the preprocessor to expand it for you:
>
> $ gcc -E - < > #include  /* NULL is defined somewhere in here */
> > void *p = NULL;
> > EOF
> void *p = ((void *)0);
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Also, there are a lot of assumptions that the return value of strlen is 
an int... Obviously, the chance of a string exceeding the 32-bit 
boundary is fairly rare, and you certainly wouldn't want to call strlen 
on a string that big, but the manpage says what it says, and strlen 
returns a size_t.

It would be A Bad Thing to change the function declarations that cause 
this I assume, as it would break ABI compatibility. However, for 
function-local variables that make this mistake, should it be fine to 
fix this? Or is it more appropriate to cast strlen to an int?


Jake Goulding wrote:
> Of course, that would have made more sense... :-)
>
> http://www.myxopho.be/glib-win64-compile.log
> And grepped for warning:
> http://www.myxopho.be/glib-win64-warnings.log
>
>
> Tor Lillqvist wrote:
>   
>> You wouldn't have the file names and line numbers for those
>> warnings...? (Maybe you could put the whole compilation output
>> listing up on the web somewhere.)
>>
>> --tml
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>>   
>> 
>
>   

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Morten Welinder]

> Or is it more appropriate to cast strlen to an int?

I would really hate to see that.  It could easily mask more important
problems later.

Note, that if you really want to change something, it is probably safer
to change it to a gssize, i.e., the signed type of the same width as
size_t.  You'll get far fewer surprises with C's handling of signed and
unsigned types that way.

IMHO, don't worry about strlen now.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

Morten Welinder writes:
 > ">=", I think, but yes.  You need to make sure configure defines gsize
 > as unsigned long long, and gssize as long long.

Jake is using the MSVC makefiles which doesn't run any configure
script (because there is no Bourne shell to run it in, etc...).

He uses the more or less manually written config.h.win32(.in) as
config.h and glibconfig.h.win32.in as glibconfig.h. If he is using the
stock config.h.win32 and glibconfig.h.win32 they will be very wrong
for Win64.

The intention is that config.h.win32 and glibconfig.h.win32 match what
running the configure script would produce, with just
compiler-specific ifdefs added (like using the "i64" suffix instead of
"ll" for 64-bit ints and unsigneds with MSVC).

It is/was expected that config.h.win32(.in) and
glibconfig.h.win32(.in) need to be updated as necessary for win64. I'm
sorry if I didn't remember to point this out early on. For instance,
the macros GLIB_SIZEOF_VOID_P, GLIB_SIZEOF_SIZE_T and the typedefs for
gsize and gssize in glibconfig.h.win32.in need to be made conditional
on _WIN64 or whatever the proper feature test macro is.

As soon as there then is a chance to run the real configure script for
the win64 target (either once gcc etc have been ported, or by using
some of the wrappers that make cl.exe look like gcc
command-line-parameter-wise), the config.h and glibconfig.h files it
outputs should be compared to config.h.win32 and glibconfig.h.win32
files that have been manually edited for Win64, and any discrepancies
fixed.

(I definitely think it would be a very bad idea to typedef glong as an
64-bit integer on win64, with plain "long" still being 32 bit. Surely
the expected convention is that "glong" is *exactly* the same as
"long"?)

(Whether having "long" being 32-bit in Win64 is a silly design
decision or not is pointless to discuss here. I am sure MS did a
thorough analysis and came to the conclusion that this causes less
problems than going to 64-bit longs.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jonathan Chambers]

Just wanted to note that I am interested in this topic as well, as I am
trying to port mono (which depends on glib) to Win64. I just contacted Tor
about this a week ago offline. I saw this thread searching the web, and just
joined the list.

Jake, if you want/need any help with anything let me know as I would be
interested/willing to do so. I haven't worked on gtk previously, but I have
ported a few apps to win64. But, I don't want to duplicate any effort.

I agree with Tor that glong should correspond to long. Any place where a
variable needs to be platform sized should use something other than a glong,
IMO. I do have a list of issues dealt with when porting to Win64, if anyone
is interested.

Just for trivia, I seem to recall that MS decided to leave long 32-bits on
all platforms because they determined that too many people had written longs
to binary files, binary blobs in databases, etc.

Thanks,
Jonathan

On 3/4/07, Tor Lillqvist <[EMAIL PROTECTED]> wrote:


Morten Welinder writes:
> ">=", I think, but yes.  You need to make sure configure defines gsize
> as unsigned long long, and gssize as long long.

Jake is using the MSVC makefiles which doesn't run any configure
script (because there is no Bourne shell to run it in, etc...).

He uses the more or less manually written config.h.win32(.in) as
config.h and glibconfig.h.win32.in as glibconfig.h. If he is using the
stock config.h.win32 and glibconfig.h.win32 they will be very wrong
for Win64.

The intention is that config.h.win32 and glibconfig.h.win32 match what
running the configure script would produce, with just
compiler-specific ifdefs added (like using the "i64" suffix instead of
"ll" for 64-bit ints and unsigneds with MSVC).

It is/was expected that config.h.win32(.in) and
glibconfig.h.win32(.in) need to be updated as necessary for win64. I'm
sorry if I didn't remember to point this out early on. For instance,
the macros GLIB_SIZEOF_VOID_P, GLIB_SIZEOF_SIZE_T and the typedefs for
gsize and gssize in glibconfig.h.win32.in need to be made conditional
on _WIN64 or whatever the proper feature test macro is.

As soon as there then is a chance to run the real configure script for
the win64 target (either once gcc etc have been ported, or by using
some of the wrappers that make cl.exe look like gcc
command-line-parameter-wise), the config.h and glibconfig.h files it
outputs should be compared to config.h.win32 and glibconfig.h.win32
files that have been manually edited for Win64, and any discrepancies
fixed.

(I definitely think it would be a very bad idea to typedef glong as an
64-bit integer on win64, with plain "long" still being 32 bit. Surely
the expected convention is that "glong" is *exactly* the same as
"long"?)

(Whether having "long" being 32-bit in Win64 is a silly design
decision or not is pointless to discuss here. I am sure MS did a
thorough analysis and came to the conclusion that this causes less
problems than going to 64-bit longs.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Jonathan:

I'd definitely like to see the list of issues that you have dealt with 
previously. Anything to minimize work is welcome in my book! :-)

Based on the various (well-argued) dissent shown to making a glong 64 
bit, I undid my change. That does leave me with the issue that there are 
a bunch of assumptions that

sizeof(long) == sizeof(size_t) == sizeof(void *)

Any suggestions on how best to tackle that issue?

Let me know what kind of help you would be interested in doing!

-Jake

Jonathan Chambers wrote:
> Just wanted to note that I am interested in this topic as well, as I 
> am trying to port mono (which depends on glib) to Win64. I just 
> contacted Tor about this a week ago offline. I saw this thread 
> searching the web, and just joined the list.
>
> Jake, if you want/need any help with anything let me know as I would 
> be interested/willing to do so. I haven't worked on gtk previously, 
> but I have ported a few apps to win64. But, I don't want to duplicate 
> any effort.
>
> I agree with Tor that glong should correspond to long. Any place where 
> a variable needs to be platform sized should use something other than 
> a glong, IMO. I do have a list of issues dealt with when porting to 
> Win64, if anyone is interested.
>
> Just for trivia, I seem to recall that MS decided to leave long 
> 32-bits on all platforms because they determined that too many people 
> had written longs to binary files, binary blobs in databases, etc.
>
> Thanks,
> Jonathan
>
> On 3/4/07, *Tor Lillqvist* <[EMAIL PROTECTED] > 
> wrote:
>
> Morten Welinder writes:
> > ">=", I think, but yes.  You need to make sure configure defines
> gsize
> > as unsigned long long, and gssize as long long.
>
> Jake is using the MSVC makefiles which doesn't run any configure
> script (because there is no Bourne shell to run it in, etc...).
>
> He uses the more or less manually written config.h.win32(.in) as
> config.h and glibconfig.h.win32.in 
> as glibconfig.h. If he is using the
> stock config.h.win32 and glibconfig.h.win32 they will be very wrong
> for Win64.
>
> The intention is that config.h.win32 and glibconfig.h.win32 match what
> running the configure script would produce, with just
> compiler-specific ifdefs added (like using the "i64" suffix instead of
> "ll" for 64-bit ints and unsigneds with MSVC).
>
> It is/was expected that config.h.win32(.in) and
> glibconfig.h.win32 (.in) need to be updated as necessary for
> win64. I'm
> sorry if I didn't remember to point this out early on. For instance,
> the macros GLIB_SIZEOF_VOID_P, GLIB_SIZEOF_SIZE_T and the typedefs for
> gsize and gssize in glibconfig.h.win32.in
>  need to be made conditional
> on _WIN64 or whatever the proper feature test macro is.
>
> As soon as there then is a chance to run the real configure script
> for
> the win64 target (either once gcc etc have been ported, or by using
> some of the wrappers that make cl.exe look like gcc
> command-line-parameter-wise), the config.h and glibconfig.h files it
> outputs should be compared to config.h.win32 and glibconfig.h.win32
> files that have been manually edited for Win64, and any discrepancies
> fixed.
>
> (I definitely think it would be a very bad idea to typedef glong as an
> 64-bit integer on win64, with plain "long" still being 32 bit. Surely
> the expected convention is that "glong" is *exactly* the same as
> "long"?)
>
> (Whether having "long" being 32-bit in Win64 is a silly design
> decision or not is pointless to discuss here. I am sure MS did a
> thorough analysis and came to the conclusion that this causes less
> problems than going to 64-bit longs.)
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org 
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
> 
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>   

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Also, I ran into a similar problem with some date functions (gmtime 
expects a 64-bit number as time_t is 64-bit)...

It's almost like there should be a full-width type, one that is 32 bits 
on a 32-bit platform, and 64 bits on 64-bit.

Thoughts?


Jake Goulding wrote:
> That does leave me with the issue that there are 
> a bunch of assumptions that
>
> sizeof(long) == sizeof(size_t) == sizeof(void *)
>
> Any suggestions on how best to tackle that issue?
>   

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

 > It's almost like there should be a full-width type, one that is 32 bits 
 > on a 32-bit platform, and 64 bits on 64-bit.

intptr_t and uintptr_t? Does the current MS compiler have ?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Owen Taylor]

On Mon, 2007-03-05 at 11:06 -0500, Jake Goulding wrote:
> Jonathan:
> 
> I'd definitely like to see the list of issues that you have dealt with 
> previously. Anything to minimize work is welcome in my book! :-)
> 
> Based on the various (well-argued) dissent shown to making a glong 64 
> bit, I undid my change. That does leave me with the issue that there are 
> a bunch of assumptions that
> 
> sizeof(long) == sizeof(size_t) == sizeof(void *)
> 
> Any suggestions on how best to tackle that issue?
> 
> Let me know what kind of help you would be interested in doing!

Can you give some examples?
- Owen


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jonathan Chambers]

Very unfortunately no. You can use the capital case windows defines,
INT_PTR, etc, or ship a version of  to use in VS (
http://www.azillionmonkeys.com/qed/pstdint.h).

- Jonathan

On 3/5/07, Tor Lillqvist <[EMAIL PROTECTED]> wrote:


> It's almost like there should be a full-width type, one that is 32 bits
> on a 32-bit platform, and 64 bits on 64-bit.

intptr_t and uintptr_t? Does the current MS compiler have ?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Sure. Please excuse the following formatting...

gbookmarkfile.c(1838) : warning C4267: 'function' : conversion from 
'size_t' to 'gulong', possible loss of data
all_data_dirs = g_new0 (gchar *, g_strv_length ((gchar 
**)system_data_dirs) + 2);

gfileutils.c(565) : warning C4267: 'function' : conversion from 'size_t' 
to 'gulong', possible loss of data
tmp = g_try_realloc (str, total_allocated);

gkeyfile.c(3330) : warning C4267: 'function' : conversion from 'size_t' 
to 'gulong', possible loss of data
string_value = g_new0 (gchar, strlen (value) + 1);

goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to 
'gulong', possible loss of data
change->allocated.array.data = g_renew (gchar *, 
change->allocated.array.data, change->allocated.array.len + 2);

And more. It sure looks like most of them have to do with the allocation 
functions, which all seem to take ulongs as opposed to size_t.

Owen Taylor wrote:
> Can you give some examples?
>   

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Are you sure?

$ cat intptr.c
#include 
#include 
#include 
#include 

#define SIZE(x) printf(#x ": %d\n", sizeof(x))

int
main(int argc, char **argv)
{
SIZE(intptr_t);
SIZE(uintptr_t);
return 0;
}

$ ./intptr.exe
intptr_t: 8
uintptr_t: 8


Jonathan Chambers wrote:
> Very unfortunately no. You can use the capital case windows defines, 
> INT_PTR, etc, or ship a version of  to use in VS 
> (http://www.azillionmonkeys.com/qed/pstdint.h 
> ).
>
> - Jonathan
>
> On 3/5/07, *Tor Lillqvist* <[EMAIL PROTECTED] > 
> wrote:
>
> > It's almost like there should be a full-width type, one that is
> 32 bits
> > on a 32-bit platform, and 64 bits on 64-bit.
>
> intptr_t and uintptr_t? Does the current MS compiler have ?
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org 
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
> 
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>   

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Between stdio.h, stdlib.h, assert.h, and windows.h it exists and is 64-bit.
Would the appropriate thing to be to change the glib code where the 
aforementioned assumptions occur to use these types?


Tor Lillqvist wrote:
>  > It's almost like there should be a full-width type, one that is 32 bits 
>  > on a 32-bit platform, and 64 bits on 64-bit.
>
> intptr_t and uintptr_t? Does the current MS compiler have ?
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>   

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

> > intptr_t and uintptr_t? Does the current MS compiler have ?

> Between stdio.h, stdlib.h, assert.h, and windows.h it exists and is 64-bit.
> Would the appropriate thing to be to change the glib code where the 
> aforementioned assumptions occur to use these types?

You mean for instance for the n_bytes parameter to g_malloc() and
friends?

I'm not sure. This can be considered as an API change even if the type
is the same size and signedness as the old one on the existing
plaforms. intprt_t and uintprt_t also don't exist on all
platforms. Maybe preprocessor macros is the only way out, i.e. having
a macro G_NBYTES_T (or whatever) that expands to gulong on everything
except Win64 and other similar platforms, where it would be size_t?

I.e., in gtypes.h or gmacros.h:

#if GLIB_SIZEOF_LONG < GLIB_SIZEOF_SIZE_T
#define G_NBYTES_T gsize
#else
#define G_NBYTES_T gulong
#endif

and in gmem.h:

gpointer g_malloc (G_NBYTES_Tn_bytes) G_GNUC_MALLOC;
gpointer g_malloc0(G_NBYTES_Tn_bytes) G_GNUC_MALLOC;
gpointer g_realloc(gpointer  mem,
   G_NBYTES_Tn_bytes) G_GNUC_WARN_UNUSED_RESULT;
void g_free   (gpointer  mem);
gpointer g_try_malloc (G_NBYTES_Tn_bytes) G_GNUC_MALLOC;
gpointer g_try_malloc0(G_NBYTES_Tn_bytes) G_GNUC_MALLOC;
gpointer g_try_realloc(gpointer  mem,
   G_NBYTES_Tn_bytes) G_GNUC_WARN_UNUSED_RESULT;

Yeah, a bit ugly.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Owen Taylor]

On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:
> Sure. Please excuse the following formatting...
> 
> gbookmarkfile.c(1838) : warning C4267: 'function' : conversion from 
> 'size_t' to 'gulong', possible loss of data
> all_data_dirs = g_new0 (gchar *, g_strv_length ((gchar 
> **)system_data_dirs) + 2);
> 
> gfileutils.c(565) : warning C4267: 'function' : conversion from 'size_t' 
> to 'gulong', possible loss of data
> tmp = g_try_realloc (str, total_allocated);
> 
> gkeyfile.c(3330) : warning C4267: 'function' : conversion from 'size_t' 
> to 'gulong', possible loss of data
> string_value = g_new0 (gchar, strlen (value) + 1);
> 
> goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to 
> 'gulong', possible loss of data
> change->allocated.array.data = g_renew (gchar *, 
> change->allocated.array.data, change->allocated.array.len + 2);
> 
> And more. It sure looks like most of them have to do with the allocation 
> functions, which all seem to take ulongs as opposed to size_t.

Hmm. I think in terms of gmem.h we probably should try to fix the
ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
don't have to worry about a binary compatibility issue with changing the
prototype. And on all other platforms I know of gsize and ulong are the
same size.

There *are* platforms where gssize is an unsigned integer rather than an
unsigned long, but my general feeling is that just changing the gmalloc
prototypes is unlikely to cause problems; GMemVTable, which would be
more likely to cause warnings already has gsize there.

There are going to be other situations however, where the fix isn't so
obvious.

 - When 64-bit proofing the Unicode string bits of GLib (years ago) 
   I took the policy that:

- Counts of bytes were sized as gsize
- Counts of "items" sized larger than a byte are longs

   because it seemed very strange to me to use size_t for non-byte
   counts. But that means that something like the return value from
   g_utf8_strlen() is wrong for win32. This can't be changed in a 
   source-compatible fashion. 

   Probably the right thing to do for g_utf8_strlen() is to compute
   things internally as 64-bit, then clamp the result to 32-bits
   on return. Without the clamp:

 long size = g_utf8_strlen(str);
 gunichar chars = g_new(gunichar, size);
 for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
  *c = g_utf8_get_char(p);
 }

Is a potential buffer overflow, though a hard one to trigger. 
(Actually, it's a potential overflow currently for 32-bits. We really 
should make g_new0() not a g_malloc()-wrapping macro so we can protect 
the multiplication.)

Things like this need to be handled case-by-case. (And not all of them
are going to generate warnings! I don't think you'll get any warnings
from g_utf8_strlen())

 - There will be some cases where you'll get warnings where it is
   obvious from the code that there is no problem. Adding casts
   to suppress the warnings there should be fine.

- Owen



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

Tor Lillqvist wrote:
> I'm not sure. This can be considered as an API change even if the type
> is the same size and signedness as the old one on the existing
> plaforms. intprt_t and uintprt_t also don't exist on all
> platforms. Maybe preprocessor macros is the only way out, i.e. having
> a macro G_NBYTES_T (or whatever) that expands to gulong on everything
> except Win64 and other similar platforms, where it would be size_t?
What would stop GLib from having a gintprt? That was the original intent 
of my earlier email asking if there were an integral type that was the 
size of a pointer.

Owen Taylor wrote:
> Hmm. I think in terms of gmem.h we probably should try to fix the
> ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
> don't have to worry about a binary compatibility issue with changing the
> prototype. And on all other platforms I know of gsize and ulong are the
> same size.
>   
Right now I took the lazy way out: I changed the defines to be gsize 
instead of gulong. The amount of warnings went down dramatically. There 
are still a handful of these around, but I get a feeling that a large 
amount of those are going to be from strlen. This seems like the 
"better" way, but may not be the most *compatible* way. Tor's suggestion 
to have a define would definitely be more compatible.

>  - When 64-bit proofing the Unicode string bits of GLib (years ago) 
>I took the policy that:
>
> - Counts of bytes were sized as gsize
> - Counts of "items" sized larger than a byte are longs
>
>because it seemed very strange to me to use size_t for non-byte
>counts. But that means that something like the return value from
>g_utf8_strlen() is wrong for win32. This can't be changed in a 
>source-compatible fashion. 
>   
Your approach seems reasonable. Too bad that Win64 had to screw things 
up. :-)
>Probably the right thing to do for g_utf8_strlen() is to compute
>things internally as 64-bit, then clamp the result to 32-bits
>on return. Without the clamp:
>
>  long size = g_utf8_strlen(str);
>  gunichar chars = g_new(gunichar, size);
>  for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
> *c = g_utf8_get_char(p);
>  }
>
> Is a potential buffer overflow, though a hard one to trigger. 
> (Actually, it's a potential overflow currently for 32-bits. We really 
> should make g_new0() not a g_malloc()-wrapping macro so we can protect 
> the multiplication.)
>   
An interesting point, and one that I certainly had not thought of.
> Things like this need to be handled case-by-case. (And not all of them
> are going to generate warnings! I don't think you'll get any warnings
> from g_utf8_strlen())
>
>   
I am simply not familiar enough with GLib to know of these type of 
functions. Suggestions on finding them?
>  - There will be some cases where you'll get warnings where it is
>obvious from the code that there is no problem. Adding casts
>to suppress the warnings there should be fine.
>   
Again, my lack of familiarity will be a killer here. Hopefully asking 
this list should clear most of those up.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jonathan Chambers]

I just wanted to post on this thread again to see where things stand.

Jake, are you working on this still, and planning on sending in any patches?
If not, I may begin to take a shot at getting current branch code to compile
on Win64. I have the mono runtime semi-ported to Win64, so glib is what I
need next. I guess the best approach is to just grab current source and
begin compiling and fixing errors and warnings. Should I post diffs to this
list?

Thanks,
Jonathan

On 3/5/07, Jake Goulding <[EMAIL PROTECTED]> wrote:


Tor Lillqvist wrote:
> I'm not sure. This can be considered as an API change even if the type
> is the same size and signedness as the old one on the existing
> plaforms. intprt_t and uintprt_t also don't exist on all
> platforms. Maybe preprocessor macros is the only way out, i.e. having
> a macro G_NBYTES_T (or whatever) that expands to gulong on everything
> except Win64 and other similar platforms, where it would be size_t?
What would stop GLib from having a gintprt? That was the original intent
of my earlier email asking if there were an integral type that was the
size of a pointer.

Owen Taylor wrote:
> Hmm. I think in terms of gmem.h we probably should try to fix the
> ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
> don't have to worry about a binary compatibility issue with changing the
> prototype. And on all other platforms I know of gsize and ulong are the
> same size.
>
Right now I took the lazy way out: I changed the defines to be gsize
instead of gulong. The amount of warnings went down dramatically. There
are still a handful of these around, but I get a feeling that a large
amount of those are going to be from strlen. This seems like the
"better" way, but may not be the most *compatible* way. Tor's suggestion
to have a define would definitely be more compatible.

>  - When 64-bit proofing the Unicode string bits of GLib (years ago)
>I took the policy that:
>
> - Counts of bytes were sized as gsize
> - Counts of "items" sized larger than a byte are longs
>
>because it seemed very strange to me to use size_t for non-byte
>counts. But that means that something like the return value from
>g_utf8_strlen() is wrong for win32. This can't be changed in a
>source-compatible fashion.
>
Your approach seems reasonable. Too bad that Win64 had to screw things
up. :-)
>Probably the right thing to do for g_utf8_strlen() is to compute
>things internally as 64-bit, then clamp the result to 32-bits
>on return. Without the clamp:
>
>  long size = g_utf8_strlen(str);
>  gunichar chars = g_new(gunichar, size);
>  for (char *p = str, gunichar *c = chars; *p; p =
g_utf8_next_char(p)) {
> *c = g_utf8_get_char(p);
>  }
>
> Is a potential buffer overflow, though a hard one to trigger.
> (Actually, it's a potential overflow currently for 32-bits. We
really
> should make g_new0() not a g_malloc()-wrapping macro so we can
protect
> the multiplication.)
>
An interesting point, and one that I certainly had not thought of.
> Things like this need to be handled case-by-case. (And not all of
them
> are going to generate warnings! I don't think you'll get any
warnings
> from g_utf8_strlen())
>
>
I am simply not familiar enough with GLib to know of these type of
functions. Suggestions on finding them?
>  - There will be some cases where you'll get warnings where it is
>obvious from the code that there is no problem. Adding casts
>to suppress the warnings there should be fine.
>
Again, my lack of familiarity will be a killer here. Hopefully asking
this list should clear most of those up.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

Jonathan Chambers writes:
 > Should I post diffs to this list?

It's better to open a bug in bugzilla and attach diffs to it.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Jake Goulding]

My apologies for being lax on this. glib is part of our whole underlying 
platform of dependencies, so I ended up working on some other libraries 
for a bit.

The big thing is the parameters to the allocation functions. My gut is 
to change them to be gsize as that is pedantically correct, and indeed 
that is what I did for my changes. I suppose the final decision on that 
really needs to be made by someone higher up.

Another potentially major change for the Windows-specific stuff is to 
struct _GIOWin32Channel and struct _GPollFD. Both of these structures 
assume 32 bits in various places. GPollFD also has an int when it really 
needs a gpointer.

I have a rough cut of a big monolithic patch that worked here to get the 
glib tests to build/work. As soon as we get a bug for this (I don't seem 
to be able to access bugzilla.gnome.org right now...) I'll post the 
patch and let you take a look at it. There definitely are some things 
that are mostly useful here (little hacks I have to do to get the build 
working locally), and not nearly all of the warnings that should be 
looked at have been. I also think this would probably work as a handful 
of smaller targeted patches that address specific concerns. We can 
figure out those details once we get the code working well enough.

-Jake

Jonathan Chambers wrote:
> I just wanted to post on this thread again to see where things stand.
>
> Jake, are you working on this still, and planning on sending in any 
> patches? If not, I may begin to take a shot at getting current branch 
> code to compile on Win64. I have the mono runtime semi-ported to 
> Win64, so glib is what I need next. I guess the best approach is to 
> just grab current source and begin compiling and fixing errors and 
> warnings. Should I post diffs to this list?
>
> Thanks,
> Jonathan
>
> On 3/5/07, *Jake Goulding* < [EMAIL PROTECTED] 
> > wrote:
>
> Tor Lillqvist wrote:
> > I'm not sure. This can be considered as an API change even if
> the type
> > is the same size and signedness as the old one on the existing
> > plaforms. intprt_t and uintprt_t also don't exist on all
> > platforms. Maybe preprocessor macros is the only way out, i.e.
> having
> > a macro G_NBYTES_T (or whatever) that expands to gulong on
> everything
> > except Win64 and other similar platforms, where it would be size_t?
> What would stop GLib from having a gintprt? That was the original
> intent
> of my earlier email asking if there were an integral type that was the
> size of a pointer.
>
> Owen Taylor wrote:
> > Hmm. I think in terms of gmem.h we probably should try to fix the
> > ulong/size_t situation. There is currently no ABI for
> GLib/Win64, so we
> > don't have to worry about a binary compatibility issue with
> changing the
> > prototype. And on all other platforms I know of gsize and ulong
> are the
> > same size.
> >
> Right now I took the lazy way out: I changed the defines to be gsize
> instead of gulong. The amount of warnings went down dramatically.
> There
> are still a handful of these around, but I get a feeling that a large
> amount of those are going to be from strlen. This seems like the
> "better" way, but may not be the most *compatible* way. Tor's
> suggestion
> to have a define would definitely be more compatible.
>
> >  - When 64-bit proofing the Unicode string bits of GLib (years ago)
> >I took the policy that:
> >
> > - Counts of bytes were sized as gsize
> > - Counts of "items" sized larger than a byte are longs
> >
> >because it seemed very strange to me to use size_t for non-byte
> >counts. But that means that something like the return value from
> >g_utf8_strlen() is wrong for win32. This can't be changed in a
> >source-compatible fashion.
> >
> Your approach seems reasonable. Too bad that Win64 had to screw things
> up. :-)
> >Probably the right thing to do for g_utf8_strlen() is to compute
> >things internally as 64-bit, then clamp the result to 32-bits
> >on return. Without the clamp:
> >
> >  long size = g_utf8_strlen(str);
> >  gunichar chars = g_new(gunichar, size);
> >  for (char *p = str, gunichar *c = chars; *p; p =
> g_utf8_next_char(p)) {
> > *c = g_utf8_get_char(p);
> >  }
> >
> > Is a potential buffer overflow, though a hard one to trigger.
> > (Actually, it's a potential overflow currently for 32-bits.
> We really
> > should make g_new0() not a g_malloc()-wrapping macro so we
> can protect
> > the multiplication.)
> >
> An interesting point, and one that I certainly had not thought of.
> > Things like this need to be handled case-by-case. (And not
> all of them
> > are going to generate warnings! I don't t

Re: GLib and 64-bit Windows

[Jake Goulding]

So bugzilla is again available to me. Any tips on where to file this bug?


Jake Goulding wrote:
> As soon as we get a bug for this (I don't seem 
> to be able to access bugzilla.gnome.org right now...) I'll post the 
> patch and let you take a look at it.

-- 

JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]

Viví­simo [Search Done Right™]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com  clusty.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Fixing 32/64 bit semantics of long (Re: GLib and 64-bit Windows)

[Tim Janik]

On Wed, 30 Jan 2008, Owen Taylor wrote:

> I'm not sure what you you are asking here. What I was saying is that
> changing vtable members is more likely to break things than changing
> function prototypes.

Ok, but then, every prototype change can be a "vtable change", given a
custom vtable that has a slot expecting a certain glib API function type,
as in the g_realloc() pointer example.
(Yes, i realize that you were referring only to vtables exported by glib ;)

>> if i understand you correctly, you mean to imply that we also fix the
>> signatures from *long to *size as well for the following functions
>> (comprehensive list of *long API in glib/glib/*.h):
>>
>>
>> gdouble  g_timer_elapsed (GTimer  *timer,
>>gulong  *microseconds);
> [...]
>
> No, I didn't mean that, because
>
> gdouble  g_timer_elapsed (GTimer  *timer,
>   size_t  *microseconds);
>
> gulong microseconds;
>
> g_timer_elapsed(timer, µseconds);
>
> Will warn in many many situations on many platforms, and MSVC will warn
> about:
>
> gsize g_utf8_strlen (const gchar *p,
>  gssize   max);
>
> long value = g_utf8_strlen(p, max);
>
> even when compiling for 32 bits. So I don't consider changing out
> parameters and returns from long => size_t compatible.

H...

I think it makes sense to distinguish between changing long value
types and *long pointer types. The former is unlikely to
cause major breakage. The exception being custom vtables that
expect particular prototypes in GLib and possibly return type size
warnings (though a case can be made for wanting those
warnings i think).

We currently have these semantics for GLib types wrg 32/64bit
portability:

gint32  - 32bit on all platforms
gint64  - 64bit on all platforms
glong   - 32bit on 32 bit platforms & Win64, 64bit on 64 bit platforms
gsize   - 32bit on 32 bit platforms, 64bit on 64 bit platforms
ptrdiff_t   - 32bit on 32 bit platforms, 64bit on 64 bit platforms

That is, glong is pretty much useless. If a type is needed
that reliably widens size on 64bit system (usually needed
to store pointer values or larger memory offsets/sizes),
we actually have to use gsize.

These are the possibilities i see to solve this:

1) Define glong to ssize_t on Win64. This'll break the
assumption that long==glong on all platforms though.

2) Search+replace our headers for glong -> gssize (i.e. what
i suggested in my previous email).

3) Introduce a new type, e.g. "gwide/guwide":
#ifdef _WIN64
  typedef ssize_t gwide;
  typedef size_t  guwide;
#else /* !_WIN64 */
  typedef glong  gwide;
  typedef gulong guwide;
#endif
Then search+replace our headers for it, i.e. glong -> gwide.
This preserves "long"-ness on all currently existing platforms,
and still allows the repsective API for Win64 to be 64bit wide.

Further notes:

- Deprecate usage of "long/glong" in public headers. This should
   be part of our policy in any case. Long simply has unclear
   semantics, gint32/gint64/gsize have clear semantics wrt to
   32bit/64bit platforms.
   Deprecate use of "gwide" in favor of gint32/gint64/gsize, this
   type is only needed in places where we used to have glong in
   public API for historical reasons.

- When i say "search+replace", i'm including the types used in the
   G_TYPE_LONG API, e.g. g_value_set_long().
   Changing glong->gssize or glong->gwide there might look surprising,
   but provides clear calling semantics.
   In retrospect, i shouldn't have added support for longs to GType
   in the first place...

Out of the above, i think (1) provides potentially bad pitfalls,
because it's surprisingly inconsistent with other glib types.

The ideal solution might be (2), and i think it's worth putting it
into place in a future devel branch of GLib, with the option of
falling back to (3) if (2) turns out to cause bad breakage in
practice. I.e. (3) might be needed anyway for long pointer types
as you pointed out above, but that's the minority of API changes
(11 out of 57).

Functions with long pointers:
g_timer_elapsed
g_utf8_to_utf16
g_utf8_to_ucs4
g_utf8_to_ucs4_fast
g_utf16_to_ucs4
g_utf16_to_utf8
g_ucs4_to_utf16
g_ucs4_to_utf8
gdk_colors_alloc
gdk_colors_free
GdkEventClient

Functions/structures with long arguments and return values:
GHookList
g_hook_destroy
g_hook_get
G_STRUCT_OFFSET
G_STRUCT_MEMBER_P
GOptionEntry
g_thread_create_full
g_usleep
g_time_val_add
GTimeVal
g_utf8_offset_to_pointer
g_utf8_pointer_to_offset
g_utf8_strlen
g_snprintf
g_vsnprintf
g_bit_nth_lsf
g_bit_nth_msf
g_bit_storage
g_signal_connect_object
g_param_spec_long
g_param_spec_ulong
GParamSpecLong
GParamSpecULong
g_signal_add_emission_hook
g_signal_remove_emission_hook
g_signal_connect_closure_by_id
g_signal_connect_closure
g_signal_connect_data
g_signal_handler_block
g_signal_handler_unblock
g_signal_han