Wireshark · Ethereal-dev: Re: [ethereal-dev] no 64 bit support, gryphon plugin

[Uwe Girlich <Uwe.Girlich@xxxxxxxxxxx>]

Hello!

On Wed, Aug 09, 2000 at 03:04:52PM -0700, Guy Harris wrote:
> > Can Gryphon be made to do a perhaps-less-than-ideal dissection without
> > 64-bit integer support,

> It appears that it could; you could have "resp_time()" just display the
> time stamp as hex, rather than as a date and a time.
This is possible but I see some problems even in the 64 bit supporting
platforms:
    union {
        unsigned int            lng[2];
        guint64                 lnglng;
    } ts;
    unsigned int    timestamp;
    unsigned char   date[45];

    ts.lng[1] = pntohl ((unsigned int *)(*data));
    ts.lng[0] = pntohl ((unsigned int *)((*data)+4));
    timestamp = ts.lnglng / 100000L;
    strncpy (date, ctime((time_t*)&timestamp), sizeof(date));
    date[strlen(date)-1] = 0x00;
    proto_tree_add_text(pt, NullTVB, *offset, 8, "Date/Time: %s", date);
    timestamp = ts.lng[0];
    hours = timestamp /(100000 * 60 *60);

It looks like in the protocol we have a 64 bit number which holds the number
seconds * 100000, which is good for 5 fraction digits. But to interpret
the lnglng overlaying 2 uint is an assumtion about the order of the 2 uint
in the guint64. It will work on little-endian systems only.

The first timestamp (ts.lnglng / 100000L) should be obviously the number of
seconds (ctime() needs it so) but what is the second timestamp (ts.lng[0]).
>From the following lines (hours = ...) it should probably be the originally
value ts.lnglng, because every following statement has its own division
by 100000.

> (BTW, this indicates that we should provide "pntohll()" and "phtonll()"
> routines, and tvbuff versions of them, at least on platforms where we
> have "gint64" and "guint64".)
That would at least clean the first mentioned problem.

Uwe