> ~ 64 bit integers. Ethereal needs something like FT_UINT64 to properly
> display 64 bit integers used by several smb commands as Trans2 and
> NT Trans. As of now all 64bit integers are displayed via a sub in
> packet-smb.c which really only reads and displays the low 32 bits
> of the data.
This is not a problem unique to SMB; NFSv3, for example, has the same
issue.
We should add FT_INT64 and FT_UINT64; however, there are at least two
issues with them:
1) making the code still compile on platforms that lack "gint64"
and "guint64" - what we should probably do on those platforms
is just treat the 64-bit integers as 8-byte opaque
quantities, and display them as hex digits;
2) displaying the values on platforms that *do* support "gint64"
and "guint64" - there's no standard for the format to use to
print those quantities, and, while many of them support
"%ll[doxu]", older versions of BSD don't (they support only
"%q[doxu]"), and I don't know what the Microsoft Visual C++
library supports, if anything.
> ~ 64bit time format. Probably quite a lot of work.
> Some smb commands use a 64bit integer field to represent the date/time
> which currently is just displayed as <can not decode yet> in a
> sub in packet-smb.c.
> Perhaps we need something like FT_ABSOLUTE_TIME_64 or something.
The 64-bit time format in SMB is a FILETIME, which is a 64-bit count of
100-nanosecond intervals since midnight "GMT", January 1, 1601.
FT_ABSOLUTE_TIME is, in current top-of-tree CVS, 32 bits of seconds
since midnight GMT, January 1, 1970, and 32 bits of nanoseconds; that's
capable of representing many valid FILETIME values, with full precision.
One possibility would be to treat out-of-range values (which includes
values past the magic day in 2038) as errors for now, and represent
FILETIME values as FT_ABSOLUTE_TIME. When the last platform that can't
handle 64-bit integral quantities gains that ability or becomes
uninteresting as an Ethereal platform, we could make FT_ABSOLUTE_TIME be
64 bits of seconds since the UNIX epoch and either 32 bits of
nanoseconds or 64 bits of picoseconds or femtoseconds or attoseconds
or....
