The Blue Meanie wrote: > On Mon, 1 Aug 2005 19:57:24 +0200 > Christian Biere <[EMAIL PROTECTED]> wrote: > > The Blue Meanie wrote: > > > I did get two new > > > warnings the first time through, in utf8.c: > > > > > > "utf8.c", line 962: warning: argument #3 is incompatible with prototype: > > > prototype: pointer to unsigned int : > > > "/usr/include/glib-2.0/glib/gconvert.h", line 54 argument : > > > pointer to unsigned long > > > "utf8.c", line 962: warning: argument #5 is incompatible with prototype: > > > prototype: pointer to unsigned int : > > > "/usr/include/glib-2.0/glib/gconvert.h", line 54 argument : > > > pointer to unsigned long
> Well, maybe I went about this the wrong way. I tried to find a typedef for > gsize in the various .h files for glib/gtk, and came up empty. I just made > the correction based on the prototype I saw for g_iconv() in gconvert.h and > it seemd to work. Any idea where gsize is officially declared, so I can > double-check that it's really different from size_t? It's in "$prefix/lib/glib-2.0/include glibconfig.h". It's a machine-dependent file, therefore you won't find it in "$prefix/include". > What's the story behing the gint, glong, gsize thing anyway? I really don't know. A brain fart I guess. Just think about compatibility with libc, printf and other stuff. If gint isn't int, nothing works. There's really no point in having these duplicate types. guint32, gint32 etc. are OK since GLib pre-dates C99 which has uint32_t, int32_t etc. but the aliases for the basic C types are utter nonsense. > I get the impression the purpose was to make sure that g* types were > consistent from platform to platform. It appears that in this case, > they failed, yes? Looks like it. > > > It looks like arguments 3 and 5 to g_iconv() are declared in > > > glib/gconvert.h as "gsize". size_t and gsize appear to be different > > > lengths, at least on my system. A simple change on lines 936 and 937 of > > > utf8.c, and the entire compile was absolutely silent, warning-wise: > > > > Well but then you truncate "unsigned long" to "unsigned int". It's > > probably not a problem for use as we shouldn't use such large objects > > but it's still nonsense. This must be fixed otherwise. > Can you explain where the truncate you're talking about is happening? It > seems to me that gsize is bigger than size_t (gsize appears to be 8 bytes, > while size_t appears to be 4). Wouldn't that mean that when you call > complete_iconv you'd be passing an int into a long, leaving more room, not > the other way around? Maybe, maybe not. If you could show me the prototype of your g_iconv() instead and the definition of gsize, it would be easier to answer. I might misread the compiler warning. Is your size_t 32-bit or 64-bit? > I wonder if everyone else in LP64-land is having these issues? With the > upcoming swell in 64-bit platforms, it's starting to look like life is > going to get very difficult for coders. I don't think so. Older 64-bit platforms like Alpha, Sparc64 etc. pretty much forced everybody to fix their code, so that AMD64 has it very easy compared to the older 64-bit machines. Of course, there are many people who still think 32-bit and you probably have to wait for Windoze 64-bit being the "norm" until we can really call that history. -- Christian
pgpkVsHWFvkX0.pgp
Description: PGP signature
