Re: GLib and 64-bit Windows

[Jake Goulding <goulding vivisimo com>]

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.