From: "Guy Harris"
> > No dissector in ethereal use tvb_get_ntohll() since it requires
> > guint64 which is not available on all platforms. I suggest that
> > the 64bit accessors from epan/tvbuff.c be removed.
>
> I've just removed them.
>
> If we ever decide that we no longer care about platforms that lack
> 64-bit integer support, we can bring them back, although we'd still have
> to continue to use "u64toa()" and "u64toh()", or put some crud into the
> autoconfigure script to figure out what format is used in "printf" for
> 64-bit integers (or decide that we no longer care about UNIX platforms
> that don't use "%ll[douxX]" - some BSDs that don't document it support
> it nevertheless, along with "%q[douxX]" - and use "ll" on UNIX and "I64"
> or whatever the Microsoft C library supports on Windows).
I guess that at least for quite some time, 64bit integer fields in protocols
will
be relativly rare since I guess very few protocols actually NEED to transfer
64bit scalar types.
The only drawback I see with the current implementation of 64bit integers is
that
it is not possible to do aritmetics on them. (as you stated gryphon does in
another email)
If it seems that only very few dissector actually needs to do 64bit
aritmetics perhaps
the best solution would be to extend int-64bit.c to supply basic operations
as
int_u64bit_add(), (int_u64bit_sub()?), int_u64bit_cmp(),
int_u64bit_is_zero()
as well as an
tvb_get_64bit_opaque()
which would return an opaque type (which would
happen to be just a pointer to an array of 8 bytes, network order) which
definition
would be hidden from the applications to discourage direct use of the type.
If the need (which I suspect) for doing 64bit arithmetics in dissectors is
very very limited
(currently only one single dissector out of 200+?) then this might be
acceptable.
I will, when time permits, in the next few days look at what gryphon needs
regarding arithmetics
and implement the nessecary functions.
I will also look in the next few days into the problem with diameter
crashing when toggling desegmentation on/off
(which I can reproduce) and I suspect(guessing) might be a bug in the TCP
reassembley routines and not
in diameter.
It might take one or two days before I will get time to look into that one
further.
After that I will start providing incremental patches for smb.
(who needs computer games when hacking ethereal is much more fun and
rewarding)
have fun,
ronnie sahlberg
