--enable-extra-gcc-checks set.
If we turn on -pedantic, try turning on -Wno-long-long as well, so that
it's not *so* pedantic that it rejects the 64-bit integral data types
that we explicitly require.
Constify a bunch of stuff, and make some other changes, to get rid of
warnings.
Clean up some indentation.
svn path=/trunk/; revision=21526
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
add a config.nmake option to control whether to build
libethereal.dll or not;
remove "./wiretap" from PATH to prevent problems due to
wrongly-loaded files;
build dissector.lib with MSVC;
move "print.c" and "ps.c" to the dissector helpers, as "print.c"
imports variables from packet-frame.c and packet-data.c, which
are in libethereal;
move "g711.c" out of the dissector helpers, as they're used only
by Ethereal in a tap, not in Tethereal or in any dissector;
add a .def file for libethereal;
arrange to declare global variables exported from libethereal
with "__declspec(dllimport)" when building programs that import
those variables;
update the NSIS installer.
Make the "configure" script define ETH_VAR_IMPORT as "extern".
svn path=/trunk/; revision=10834
it's handed a pointer, which means that "epan_dissect_prime_dfilter()"
doesn't do so either; make that argument a "const dfilter_t *" in both
cases.
svn path=/trunk/; revision=6239
A little work still needs to be done on the new NCP dissector -- make
some of the COL_INFO texts more useful, handle a Unicode issue, and
modify some of the cases that use "request conditions".
But the NCP dissector as it stands is very usable now.
Note: I didn't merge in the PROTO_LENGTH_UNTIL_END macro... I wanted
to think about the various possible macros and review an email conversation
I had with Guy on the subject.
svn path=/trunk/; revision=5432
"epan/..." pathnames, so as to avoid collisions with header files in any
of the directories in which we look (e.g., "proto.h", as some other
package has its own "proto.h" file which it installs in the top-level
include directory).
Don't add "-I" flags to search "epan", as that's no longer necessary
(and we want includes of "epan" headers to fail if the "epan/" is left
out, so that we don't re-introduce includes lacking "epan/").
svn path=/trunk/; revision=4586
Put a hash-table of "interesting" fields in the per-proto-tree data.
The dfilter code records which fields/protocols are "interesting" (by which
I mean, their value or existence is checked). Thus, the proto_tree routines
can create special arrays of field_info*'s that are ready for the dfilter
engine to use during a filter operation.
Also store the "proto_tree_is_visible" boolean, renamed "visible", in
the per-proto-tree data.
Move epan_dissect_t to its own header file to make #include dependencies
easier to handle.
Provide epan_dissect_fill_in_columns(), which accepts just the epan_dissect_t*
as an argument.
epan_dissect_new() needs to be followed by epan_dissect_run() for the
dissection to actually take place. Between those two calls,
epan_dissect_prime_dfilter() can be run 0, 1, or multiple times in order to
prime the empty proto_tree with the "intersesting" fields from the dfilter_t.
svn path=/trunk/; revision=4422
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