Hi list,
attached is a new version of the FT_UINT64 patch.
This patch has proper error checking and should be production quality.
It applies ontop of my previous smb patch.
It fixes all 64bit integer fields in packet-nfs to use FT_UINT64
It fixes one entry in packet-l2tp.c to use FT_UINT64.
It fixes one entry in packet-diameter.c to use FT_UINT64.
(interestingly, packet-diameter.c used to use guint64 and no one complained
that ethereal didnt compile, does this mean that gcc is the only compiler
used on unix hosts today?)
I could not find any other uses of 64 bit integers in the source.
This implementation of FT_UINT64 will work on all platforms, even
those that lack a 64bit scalar type.
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.
Hats off to those that designed and implemented the ftypes framework,
extremely clean and easy to use framework. well done.
That was Gilbert.
BTW, should that framework be extended to supply a "to-string" routine,
to go along with its "from-string" routine?
We might want two such routines, one to generate a string that could be
passed to the "from-string" routine, for use by, say,
"proto_alloc_dfilter_string()", and another to generate a "friendly"
string, for use by, say, "proto_item_fill_label()" - the latter might
include the value from a value_string table, or the name corresponding
to a network address, as well as the raw value, and might include
decorations such as the word "seconds" for FT_RELATIVE_TIME
I think that this would be a good idea.
However, those routines would need to take FT_xxx and BASE_xxx as
parameters so they could print the string properly.
Also, it would require epan/* to rely on external functionality as
the resolver to handle FT_IPv4/6 properly. This could potentially
mean that significant blocks of code have to move into epan/ftypes.
Also potentially the VALS()/TFS()/bitfield handling might be nessecary to
move into epan/ftypes as well.
Perhaps sending hfindex as a parameter to those to_string functions so they
could access all nessecary fields.
If ftypes would support (different types of) to-string functions
this would make it possible to clean up a lot of the functions in
various dissectors where there are explicit calls to (multiple functionally
equivalent) special to-string functions for IPv4 (and to a lesser degree
IPv6/ETHERNET/IPX).
const char *
hfindex_to_string(tvb, offset, hfindex);
?
Two such functions could be useful, one
const char *
hfindex_to_string(tvb, offset, hfindex);
that only prints the value as a string, (example "5")
and
const char *
hfindex_to_pretty_string(tvb, offset, hfindex);
that would return something prettified (example "Foo: 5 seconds")
Having a to-string for FT_IPv4(/FT_IPv6/FT_ETHER/FT_IPX) would
allow us to remove and simplify a lot of redundant code in the
dissectors.
(which also removes a lot of tvb_to_ptr() calls)
This could be the next round of maintenance cleanups to
do when all dissectors are tvbuffified (soon?)
regards
ronnie s
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Attachment:
uint64.diff.gz
Description: application/gzip-compressed
