integers.
Make FT_INT64 and FT_UINT64 add numerical values, rather than byte-array
values, to the protocol tree, and add routines to add specified 64-bit
integer values to the protocol tree.
Use those routines in the RSVP dissector.
svn path=/trunk/; revision=11796
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
equivalents for the epan/ directory but leave winsock2.h in inet_pton.c
and inet_ntop.c for now (can't estimate the consequences).
svn path=/trunk/; revision=5928
former depends on having "guint64" and the latter depends on
"%ll[douxX]" being what's used to print 64-bit integers, and there are
platforms on which Etheeal runs that don't have "guint64" or that don't
use "%ll[douxX]" to print 64-bit integers.
Get rid of the routines to extract 64-bit integers into "gint64"s and
"guint64"s, as per Ronnie Sahlberg's suggestion, to discourage people
from writing code that won't work on all platforms; they should be using
FT_UINT64, or the routines in "int-64bit.c", instead.
svn path=/trunk/; revision=4102
"epan/pint.h" - they caused GCC to whine about them being redefined when
I compiled on FreeBSD 3.4.
Get rid of the stuff in "packet-ipv6.h" that defines various bit vectors
differently depending on the byte order of the machine; instead, define
them so that they work with items in host byte order. This lets us use
a number of them rather than using hardwired hex values.
Put "frag.ip6f_offlg" in host byte order before using it; this means
that IP6F_MORE_FRAG can still be used even though it now works only on
items in host byte order.
svn path=/trunk/; revision=2610
Stig Bjørlykke