> Sorry, my linux compiler was giving me warnings. (not on the %x ones, but
> on the %d's).
On what platform? "gint32" should be "int", and "guint32" should be just
"unsigned int", on most if not all platforms; what does "glibconfig.h"
typedef it as?
(I noticed this because I'd gotten a warning here - GLib 1.2.7, Solaris
2.6/SPARC - from a "%lx" being used to print a "guint32".)
> Well, no one is actually using the 64 bit stuff in Diameter yet, but it
> is there. . . . There are a few other places where 64 bit isn't supported
> yet too (i.e. in registration . . there is no FT_UINT64)
My inclination was to add FT_INT64 and FT_UINT64, have them treated as
8-byte arrays on platforms with no 64-bit integral data type support, and
have them treated as 64-bit integral types on platforms that do have it.
The code to fetch values would need a little work - we might either have
to define our own 64-bit datatypes if G_HAVE_GINT64 isn't defined as 1,
with those datatypes just being arrays of 8 bytes or as pairs of 32-bit
integral data types on those platforms and defined as "gint64" and
"guint64" on platforms that do have 64-bit data types.
> I could just disable the 64bit for now, and display it as raw hex. Doesn't
> really matter to me until I start seing 64bit traffic :)
There are other dissectors using 64-bit integral data types, so removing
them from the DIAMETER dissector wouldn't be sufficient, so it's
probably not worth doing yet.
