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
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
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
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
X/Open specs *not* to be defined, so we also have to define
__EXTENSIONS__.
XXX - can we just define __USE_XOPEN, and not define _XOPEN_SOURCE? Is
that sufficient to get "strptime()" declared on all platforms?
svn path=/trunk/; revision=4629
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE 500
#endif
#define __USE_XOPEN
#include <time.h>
to get strptime() declared in time.h on various systems. I hope
this helps more than it hurts.
svn path=/trunk/; revision=4624
* gcc 3.0 warning fixes:
- text2pcap.c: The number of characters to scan should probably not be 0
- wiretap/csids.c: using preincrement on a variable used on both
sides of an assignment might be undefined by the C99(?) standard
* turn on additional warnings for epan and wiretap too
- epan/configure.in
- wiretap/configure.in
* Fix some warnings (missing includes, signed/unsigned, missing
initializers) found by turning on the warnings
- all other files :-)
svn path=/trunk/; revision=3709
the glibc "strptime()" (modified so it doesn't require the rest of
glibc), set up the configure script to check for it, and set up
Makefile.am and Makefile.nmake to use it.
Get rid of NEED_MKSTEMP - nothing uses it.
svn path=/trunk/; revision=3500
value.
Check that the microseconds field of an absolute time is valid, if it's
present.
Set "tm_isdst" in the "struct tm" handed to "mktime()" to -1, so that
"mktime()" will attempt to figure out whether the time is daylight
savings time or not.
Check that "mktime()" was able to convert the time.
svn path=/trunk/; revision=3487
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
Ronnie Sahlberg