Re: GLib and 64-bit Windows

["Jonathan Chambers" <joncham gmail com>]

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> 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