Re: 64bit format strings

[Tim Janik <timj gtk org>]

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
> > glibc/gcc).
>
> 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
>
>   so
>
>   guint64 foo = 5;
>   printf ("foo=%lld\n", foo);
>
>   becomes
>
>   guint64 foo = 5;
>   printf ("foo=%lld\n", (unsigned long long)foo);
>
>   this should work on any platform, even when 128bit long longs are
>   introduced

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

---
ciaoTJ