Re: GLib and 64-bit Windows

[Jake Goulding <goulding vivisimo com>]

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* < goulding vivisimo com 
> <mailto:goulding vivisimo com>> 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 <mailto:gtk-devel-list gnome org>
>     http://mail.gnome.org/mailman/listinfo/gtk-devel-list

--

JAKE GOULDING
Software Engineer
goulding vivisimo com

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