Hi! I am getting compile warnings on Linux AMD64 in places where BEAST needs to format gint64 strings, and with what glib-2.0 currently provides, I see no way of solving it within BEAST. Here is some example code:
------ /* * cc -Wall $(pkg-config --libs --cflags glib-2.0) gint64print.c -o gint64print * xgettext -a gint64print.c */ #include <glib.h> static const char * __attribute__ ((format_arg (1))) no_gettext (const char *my_format) { return my_format; } #define _(x) no_gettext(x) int main() { gint64 i = 1,j = 99; g_print ("Progress: %lld bytes copied, %lld bytes to go\n", i, j); g_print ("Progress: %" G_GINT64_FORMAT " bytes copied, %" G_GINT64_FORMAT " bytes to go\n", i, j); g_print (_("Progress: %lld bytes copied, %lld bytes to go\n"), i, j); g_print (_("Progress: %" G_GINT64_FORMAT " bytes copied, %" G_GINT64_FORMAT " bytes to go\n"), i, j); return 0; } ------ There are four possibilities I can think of when formatting a simple string. (1) Take no care that gint64 is defined by glib-2.0 as long long on 32-bit platforms and as long on 64-bit platforms. This generates compiler warnings on 64bit machines like Linux on AMD64. (2) Use glib's macros for formatting things. The code is less readable, but works. (3) Use i18n, without using glib's macros: works, but generates the same warnings on 64-bit platforms like Linux on AMD64 as (1). (4) Use i18n and glib's macros: breaks due to xgettext, which cannot deal with preprocessor string concatenation. No internalization is performed. So there are two problems with the two use cases that compile without warning: unreadable code and broken i18n. Therefore, I propose to define gint64 as long long on all systems where sizeof(long long) == 8. At least on Linux on AMD64, this resolves both problems, since then "%lld" can be used, so the code in (1) and (3) can be used and compiles without warnings. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list