Re: [Ethereal-dev] Re packet-smb.c

[Guy Harris <guy@xxxxxxxxxx>]

> ~ 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....