to_str.{c,h}. Resolved strange situation where ipx_addr_to_str was
declared in packet.h but defined in packet-ipx.c by moving
ipx_addr_to_str, ipxnet_to_str_punct, and ipxnet_to_str from packet-ipx.{c,h} to to_str.{c,h}
svn path=/trunk/; revision=3219
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
*future* version, not of 1.4, which is the *current* version - i.e.,
it's newer than 1.4) complains, if "dfilter-grammar.c" and
"dfilter-scanner.c" are part of "EXTRA_libethereal_a_SOURCES", that
"dfilter-grammar.o" is built both from "dfilter-grammar.c" and
"dfilter-grammar.y", and that "dfilter-scanner.o" is built both from
"dfilter-scanner.c" and "dfilter-scanner.l", and refuses to build
"Makefile.in".
Moving them to "EXTRA_DIST" makes 1.4b happy.
Automake 1.4 allows them either to be in "EXTRA_libethereal_a_SOURCES"
or in "EXTRA_DIST"; the only difference between the generated
"Makefile.in" files is which of those two variables the files are in,
and the only difference that makes is that it keeps those two files out
of "SOURCES", which means that "make ID" doesn't include them in the
files it looks at, and "make TAGS" and "make tags" don't include them in
the files they look at. I'm not sure whether the tags file should be
built from "dfilter-grammar.y" and "dfilter-scanner.l", or from
"dfilter-grammar.c" and "dfilter-scanner.c"; the former means you see
the real source file, not the generated source file, if you look for a
symbol defined in one of those files, while the latter means you can
look for symbols in code generated by YACC/Bison or Flex.
In either case, the generated files go into the distribution tarball,
which is what we want.
For now, we go with what makes Automake 1.4b happy.
svn path=/trunk/; revision=2909
declare it, and define a "BIT_SWAP" macro that uses it, in
"epan/bitswap.h".
Use that macro to bit-swap bytes in the IEEE 802.11 dissector, rather
than the macro that was used (said macro used GCCisms and didn't compile
on Windows).
Make an "init_plugin()" routine to enable a plugin and call its init
routine, and call it from "check_plugin_status()" and
"plugins_enable_cb()", rather than having very similar code in two
places; "patable" is now part of libethereal, and, at least on Windows,
attempts to refer to it from "libui" failed. Make "patable" static to
"epan/plugins.c". (This may still not work, as now "libui" is calling a
routine in "libethereal"; if that fails, perhaps it's time to get rid of
the "enable/disable plugins" stuff completely, as new-style plugins, at
least, register themselves as protocols and should be controllable from
the "Edit->Protocols" window just as built-in dissectors are.)
svn path=/trunk/; revision=2649
"config.h", and update it to include stuff added to "config.h" and
remove stuff removed from "config.h".
Give libethereal a "config.h.win32" and make its "Makefile.nmake" file
copy it to "config.h".
svn path=/trunk/; revision=2504
file, rather than the top-level Ethereal configuration file, check for
"inet_aton()", "inet_pton()", and "inet_ntop()". Then make its
Makefile.am include the appropriate object files if necessary.
Otherwise, they don't get built and put into libethereal, and therefore
attempts to link with anything in libethereal that uses them fail on
platforms that lack ethem, causing the build to fail.
That means a bunch of things need to be fixed to cope with libethereal
having its own "config.h" file; this means removing the include of
"config.h" from some libethereal header files. Move the definitions of
the path names used only by "resolv.c" to "resolv.c" from "resolv.h" (so
"resolv.h" doesn't need "config.h", define HAVE_PLUGINS in the configure
script (so we don't have to include it in "plugins.h" to check whether
HAVE_DLFCN_H is defined).
Unfortunately, stuff outside libethereal needs to know PLUGIN_DIR; for
now, define that in the top-level configuration file, and have Ethereal
and Tethereal pass it as an argument to "epan_init()" - that should be
cleaned up at some point.
Remove from the top-level configure script checks for things used only
in libethereal.
svn path=/trunk/; revision=2498
starting with "epan_", change the name of the library from libepan.a to
libethereal.a, and from libepan.lib to ethereal.lib.
svn path=/trunk/; revision=2492
Guy Harris