Jeff Morriss wrote:
Guy Harris wrote:
Jeff Morriss wrote:
Problem is that how you print 64-bit numbers varies. %llu doesn't
always work
...and neither does "long long" as a data type.
(for example the Windoze buildbot is now red). Instead the
PRI*64 macros should be used.
Or the G_GINT64_MODIFIER macro. I seem to remember that there was an
issue a while ago where the native *printf on Windows used %I64[doxu]
but the Windows GLib *printf routines used %ll[doxu], or something such
as that (because it had its own formatting routine).
I remembered correctly:
http://www.ethereal.com/lists/ethereal-dev/200509/msg00368.html
although, unfortunately, GLib 1.2[.x] has some severe breakage for
64-bit printing on Windows:
http://www.ethereal.com/lists/ethereal-dev/200509/msg00370.html
GLib 1.2[.x] uses the native "vsnprintf()" if present and the native
"vsprintf()" (into a buffer whose size is set from
"g_printf_string_upper_bound()") otherwise.
Unfortunately, "g_printf_string_upper_bound()" does its *own*
interpretation of the format string; it understands %q[douxX],
%L[douxX], and %ll[douxX], but *NOT* %I64[douXx].
so we may be doomed to having formatting of 64-bit values not work quite
right on Windows builds with GTK+ 1.2[.x].
As such, I checked
in a change to check for G_GINT64_MODIFIER in the top-level configure
script (as is done in the Wiretap configure script), and to use that
when printing gint64/guint64 values, rather than casting to "long long"
or "unsigned long long".
You mean rather than using %lld or %llu?
Yes. %ll[doux] is definitely wrong - especially given that, on LP64
platforms, gint64/guint64 might just be a long, not a long long.
Should the PRI*64 macros (which I just recently started adding--meaning
there were some there before, it's just that only recently did /I/ add
some) be replaced with G_GINT64_MODIFIER?
Yes (except for calls that use printf/fprintf/sprintf/snprintf rather
than the GLib equivalents, if any; there should be as few of those as
possible). We should also update the documentation.