On Wed, Apr 09, 2003 at 07:40:58PM -0700, Jaime Fournier wrote:
> Please review,
...
> + guint64 volume, tokenid, type, errorids;
...
> + if (check_col (pinfo->cinfo, COL_INFO))
> + col_append_fstr (pinfo->cinfo, COL_INFO,
> + " :FSID:%llu inode:%u type: %llu tokenid: %llu", volume,
> + inode, type, tokenid);
> +
To quote "doc/README.developer":
Don't use "long long"; use "gint64" or "guint64", and only do so
^^^^^^^^^^^^^^
if G_HAVE_GINT64 is defined. Make sure your code works even if
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
G_HAVE_GINT64 isn't defined, even if that means treating 64-bit
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
integral data types as opaque arrays of bytes on platforms where
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
it's not defined. Also, don't assume you can use "%lld",
^^^^^^^^^^^^^^^^
"%llu", "%llx", or "%llo" to print 64-bit integral data types -
not all platforms support "%ll" for printing them.
> + if (errorids)
> + {
> + if (check_col (pinfo->cinfo, COL_INFO))
> + col_append_fstr (pinfo->cinfo, COL_INFO, " : errorids: %u", errorids);
> + }
"%u" won't work for a 64-bit integral quantity on any 32-bit platform.
There are routines to format 64-bit quantities, stored as arrays of 8
bytes in network byte order, to decimal or hex strings; those routines
work even if the compiler and C library don't support 64-bit integral
quantities and "%ll[doux]". See "epan/int-64bit.h".
To handle DCE RPC, they'd have to be changed to take a byte order
argument, or new routines to handle little-endian values would be
needed, or routines to fetch 64-bit quantities would need to be added.
