On Tue, 2008-01-29 at 15:12 +0100, Tim Janik wrote: > 2008-01-29 14:58:31 Tim Janik <timj imendio com> > > * glib/gmem.[hc]: changed size argument type from gulong to gsize as > discussed on gtk-devel-list: > http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html > this should be ABI compatible on all platforms except win64 for which > no ABI binding port exists yet. > > > 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 So, changing the gmem.h prototypes actually broke compilation of gnome-keyring. (It was passing g_realloc into a function that took a function pointer; causing a warning, and with -Werror on, a fatal error.) My feeling is that this is *probably* OK (in the context of a between-major-version releases), though if more problem start showing up, changing the prototypes only for Win64 might be necessary. > > more likely to cause warnings already has gsize there. > > i suppose you mean gsize (which is always unsigned), because gssize is > always signed. I'm not sure what you you are asking here. What I was saying is that changing vtable members is more likely to break things than changing function prototypes. > > 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. > > C++ does this all the time though (also calls it's .get_number_of_elements() > methods .size()), so you get used to it after a bit of STL fiddling. > > > 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.) > > if i understand you correctly, you mean to imply that we also fix the > signatures from *long to *size as well for the following functions > (comprehensive list of *long API in glib/glib/*.h): > > > gdouble g_timer_elapsed (GTimer *timer, > gulong *microseconds); [...] No, I didn't mean that, because gdouble g_timer_elapsed (GTimer *timer, size_t *microseconds); gulong microseconds; g_timer_elapsed(timer, µseconds); Will warn in many many situations on many platforms, and MSVC will warn about: gsize g_utf8_strlen (const gchar *p, gssize max); long value = g_utf8_strlen(p, max); even when compiling for 32 bits. So I don't consider changing out parameters and returns from long => size_t compatible. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part