32-bit numbers. Separate signed and unsigned accessors have been
added and used where appropriate.
Definitely not for 0.99.5.
svn path=/trunk/; revision=20472
this primarily removes code and simplifies (==eliminates) the need to track the data that is allocated and should potentially be slightly faster than a slab allocator.
however these functions are called A LOT so there might be a performance hit when using emem with full debugging canary values and all the bells and whistles activated.
this change also makes any future attempt to parallellize dissection of frames easier if we just make the ep allocator allocate from a threads specific ep pool.
(something we would have to do anyway to make ep allocations multithreaded)
this works in all my tests so far but needs more test coverage.
svn path=/trunk/; revision=20194
print register numbers as unsigned (they're guint32);
when printing a PUT_FVALUE instruction, show the value as well
as the type of the value.
That requires that a bunch of types get to_repr methods; add them for
PCRE (FTREPR_DFILTER-only - show the regular expression as text),
tvbuffs (FTREPR_DFILTER_only - show the data as a hex string), integral
types, string types other than FT_STRING, and FT_IPv6.
That means we can use fvalue_to_string_repr() for FT_IPXNET and FT_IPv6
in proto_construct_dfilter_string(), and that we don't need to handle
integer and floating types specially in MATE.
Fix some problems with the PCRE execution code for tvbuff types.
svn path=/trunk/; revision=16369
and not free the string to which it points. Pass to
REPORT_DISSECTOR_BUG() strings allocated with ep_strdup_printf(), so
that they're freed automatically.
svn path=/trunk/; revision=16039
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
any non-printable character in hex, as "\xNN". We rely on isprint(), which
may not be the best solution because it is locale-specific.
svn path=/trunk/; revision=10707
it would make sense to add PCRE support for byte arrays containing an integer
or an IP address.
Avoid lengthy pointer constructs in cmp_matches().
svn path=/trunk/; revision=9343
New "matches" operater in display filter language. Uses PCRE.
If a "matches" operator is found in a dfilter
while libpcre has not been used to build the binary, then an
exception is thrown after using dfilter_fail() to set an apporporiate
error message.
svn path=/trunk/; revision=9182
This function is also very small, so small that teh overhead for the actual function call and return is likely to be a significant part
of its execution time.
change it into a macro and make it thus slightly faster by eliminating the function call overhead.
svn path=/trunk/; revision=9083
any previously-allocated version first, so that they don't leak memory.
From Olivier Biot: add a "proto_item_append_string()" routine, to append
to the string value a protocol tree item has.
svn path=/trunk/; revision=8821
Besides "STRING", there is now "UNPARSED_STRING", where the distinction
is that "STRING" was a double-quoted string and "UNPARSED_STRING" is just
a sequence of characters that the scanner didn't know how to scan/parse,
so it's up to the Ftype to parse it.
This gives us more flexibility and prepares the dfilter parsing engine
for the upcoming addition of the "contains" operator.
In the process of doing this, I also re-did the double-quoted string
support in the scanner, so that instead of the naively-simple support we
used to have, double-quoted strings now can have embedded dobule-quotes,
embedded octal sequences, and embedded hexadecimal sequences:
"\"" embedded double-quote
"\110" embedded octal
"\x48" embedded hex
Enhance the dfilter unit test script to be able to run a single collection
of tests instead of having to run all of them all the time.
svn path=/trunk/; revision=8083
of their value. Provide such a method for FT_BYTES, FT_UINT_BYTES,
and FT_ETHER. Have proto_alloc_dfilter_string() use the new methods.
This is part of a movement of ftype-related code out of proto.c and
into the ftype code. The immediate effect is that generated display
filters for long byte sequences don't incorrectly have trailing periods
("...") to indicate continuation.
svn path=/trunk/; revision=7100
scripts, and check in changes to add _U_ to some unused arguments (some
other should perhaps be used, so we leave the _U_ out so that the
warnings serve as a reminder to check those).
svn path=/trunk/; revision=4848
function that computes the natural logarithm of a double. Using it as
the name of a pointer to a routine to do logging can cause namespace
collisions; in fact, it *does* cause them on AIX. Rename the function
argument to "logfunc".
svn path=/trunk/; revision=4700
into epan/ftypes.
Re-write display filter routines using Lemon parser instead of yacc.
Besides using a different tool, the new grammar is much simpler, while
the display filter engine itself is more powerful and more easily extended.
Add dftest executable, to test display filter "bytecode" generation.
Add option to "configure" to build dftest or randpkt, both of which are not
built by default.
Implement Ed Warnicke's ideas about dranges in the new display filter and
ftype code.
Remove type FT_TEXT_ONLY in favor of FT_NONE, and have protocols registered
as FT_PROTOCOL. Thus, FT_NONE is used only for simple labels in the proto tree,
while FT_PROTOCOL is used for protocols. This was necessary for being
able to make byte slices (ranges) out of protocols, like "frame[0:3]"
Win32 Makefile.nmake's will be added tonight.
svn path=/trunk/; revision=2967