Re: 64bit format strings

On Fri, 21 Jan 2005, Stefan Westerfeld wrote:

On Thu, Jan 20, 2005 at 09:10:44PM +0100, Tim Janik wrote:

no. while i'm currently not able to tell you what else to do to get
rid of these warnings, i believe G_GINT64_FORMAT to not be the solution.

for one, scattering format strings with G_GINT64_FORMAT makes the code
utterly unreadable, and for another, it doesn't properly cooperate with
i18n of strings either. (you don't translate "foo error: %lld < 0" twice
into all languages, once for %lld and once for %ld).

platform changes should not require format strings to change, if that
is the case, it's a bug and needs to be fixed (prolly somewhere in

Well, the problem is that the C Standard (however, my understanding of
the standard may be limited) only specifies printf format specifiers for
C types, such as int, long and long long. Those, however, do not have a
length guarantee. This is why glib defines its own data types, such as
gint64 and guint64. However, they do not correspond to a C type; or
rather, they do not correspond to _the same_ C type on each platform.

well, sounds like that would be worth fixing then.
i.e. make glib define gint64 to long long on 64bit systems, so
the format specifiers match again. you might want to raise that
on gtk-devel-list.

Thus, there is no printf format specifier for this. So what are the
alternatives that I see now?

* do not use gint64 and guint64 in BEAST, but rather our own typedef
  (such as SfiNum) which then can be defined to long long

not really suitable, there's lots of code that had to be changed for this.

  this currently works, as long long is 64bit on all platforms that I
  know of; however, as 128bit processors get introduced, platforms
  that have 64bit longs may have 128bit long longs.

"may". there's no single instance of support for 128bit types that i know
of so far. so i'd rather wait and see what compiler builders are going
to do to provide such types, maybe the C standard will be faster for an
exception and define a "big long int" type to construct a 128bit type ;)

* continue using gint64 and guint64, but introduce a cast to long long
  whereever printf is used


  guint64 foo = 5;
  printf ("foo=%lld\n", foo);


  guint64 foo = 5;
  printf ("foo=%lld\n", (unsigned long long)foo);

  this should work on any platform, even when 128bit long longs are

i'm very much against casts if they can be at all avoided.
casts usually indicate a glitch in the whole system, a location where
different parts don't correctly fit together. also casts disable the
compilers code checking ability, so very often a cast actually hides
buggy code.
here, i think the problem is more that of gint64 not being long long,
rather than lack of casts on our side.

* implement a C++ based mechanism for format strings based on

* use "cout << foo << endl;" however, this will not really work with i18n
  either, so I suppose it is not an option

Note that I have intentionally also suggested options which have C++
porting of all (much) code as precondition, because I intend to port
things anyway. Thus it doesn't make much difference on whether to port
first, and then fix the warnings, or do it the other way round, from the
perspective of the final result.

i think that is the wrong perspective to begin with. we're on our way with
the C++ port for roughly 2.5 years now, and i think it'll take another 2
or so years to complete it, so i'm not planning fixes or other vital features
that depend on the ports completion.

  Cu... Stefan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]