Fix one instance of this bug and verify all other uses of dissect_per_sequence_of in h225.
Fix one ett field we forgot to initialize.
This fixes the problem reported with a crash earlier.
(ethereal still crashes but now inside the machinegenerated h235 dissector)
svn path=/trunk/; revision=11221
Rename "browser_open_program_file()" to "browser_open_data_file()", and
make it open files relative to the application's data directory, as
that's where data files such as HTMLized man pages would be put. (That
happens to be the program directory on Windows, but it's a different
directory on UN*X - and you aren't guaranteed to be able to find the
program directory on UN*X by looking at argv[0] in any case.) Move it
to "gtk/webbrowser.c".
Fix "filename2url()" to put "file://", not just "file:", in front of
pathnames on UN*X.
svn path=/trunk/; revision=11216
webpages from http://www.ethereal.com. This functionality is copied from
the Gimp.
Win32 will use ShellExecute to use the system registered webbrowser.
On unix builds, currently the mozilla browser is hardcoded, we still need a
preference setting for this (I will add this later).
svn path=/trunk/; revision=11206
the protocol tree for the fragment, regardless of whether the fragment
has any flags set or not, and, in that common code, handle fragments
with 0 bytes of data specially (at least in NDS, you can get zero-length
fragments - including the last fragment, so you can't just ignore those
fragments; the last fragment has to be added to finish off the
reassembly).
svn path=/trunk/; revision=11198
This matters for "update of list in real time" (sync_mode) only,
as in normal mode you wouldn't otherwise have the possibility
to stop the capture.
svn path=/trunk/; revision=11194
This will prevent getting the preview information take a lot of time for
*very* long capture files. However, on a Pentium-M 1.6 even a 35MB
capture file will not timeout in this 3 second interval.
svn path=/trunk/; revision=11192
Make "cf_name" a "const gchar *", as, at least in GTK+ 2.x, a "const
gchar *" is assigned to it. (If it's just a "gchar *" being assigned to
it, declaring it a "const gchar *" does no harm.)
svn path=/trunk/; revision=11190
before the start time, due to packet time stamp bogosity, neither a
signed value nor an unsigned value will give a sensible answer, and it
doesn't need to be a "long" as the capture's unlikely to span more than
2^32-1 seconds, again modulo packet time stamp bogosity). That
eliminates some format item vs. value warnings.
Make the packet count an "unsigned int" (it can't be negative, and we're
unlikely to have more than 2^32-1 packets - and, if we are, it should be
made a guint64). That eliminates some more format item vs. value
warnings.
Initialize "start_time" and "stop_time" to 0, so that we handle files
with no packets (and so that we don't get uninitialized variable
warnings).
Display the file size with PRIu64, after casting it to "guint64" (that
way we handle file sizes if they're "unsigned int", "unsigned long", or
a 64-bit type on ILP64 platforms (it's 64 bits in BSDs derived from
4.4BSD, even on ILP64 platforms).
Mark the first argument to "file_open_entry_changed()" as unused.
Don't use G_CONST_RETURN, as it's not defined by GLib 1.2[.x].
Get rid of an unused variable.
Clean up white space.
svn path=/trunk/; revision=11189
relative to the beginning of the connection (for TP1-4). They are *not*
relative to the first segment of a segmented TPDU, so the sequence
number can't be used in calls to "fragment_add_seq_check()".
For now, we assume that COTP packets are seen in order, and just use
"fragment_add_seq_next()" - that's unlikely to make anything worse (the
only time when "fragment_add_seq_check()" will work is when the first
segment has a sequence number of 0), and definitely fixes reassembly in
a number of cases. In the long term, we might want to handle
out-of-order packets above the reassembly layer, so that it handles even
out-of-order unsegmented packets.
svn path=/trunk/; revision=11188
use to format 64-bit integers.
Fix the RSVP dissector to use that rather than hardcoding "%ll" in.
Remove the "only if G_HAVE_GINT64 is defined" bit from the discussion of
64-bit integers - we're too dependent on having them to support
compilers that don't have a 64-bit integral data type. Do, however,
note that neither "long" nor "long long" are acceptable, and also note
that you shouldn't assume "%ll" does the trick for printing them.
svn path=/trunk/; revision=11182
"long").
Make "elapsed_time" an "unsigned int" rather than an "unsigned long" -
2^32-1 seconds is about 136 years, so on LP64 machines that won't
matter, and on ILP32 machines it doesn't make any difference, but it
*does* generate compiler warnings from "%u" being used with "unsigned
long" values.
svn path=/trunk/; revision=11181
