64bit format strings

[Stefan Westerfeld <stefan space twc de>]

   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