Re: GLib and 64-bit Windows

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-> = g_renew (gchar *, 
> change->, 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

 - 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

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]