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.
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
