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
Attachment:
signature.asc
Description: This is a digitally signed message part