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
Removed the GMemChunk used to allocate/free field_info structures
and used a free list to store the freed structs until they are allocated again.
Ethereal will allocate more field_info structs as it needs to but never free them. Instead the are just placed in a cheap and fast free list so that if we
want to use the struct again, this will be fast.
This affects the speed of the two functions
alloc_field_info() that should be slightly faster now
free_field_info() that was replaced with a 2 line macro.
All in all my testing suggests that ethereal is 2-3% faster with this patch.
svn path=/trunk/; revision=9073
In the GPROF logs proto_registrar_get_nth() used to take anything between 2.5 and 5.5% of the time.
Replace the GLIB array with a handroleld one for one of the private structures.
the function should now be virtually zero cost
and thus ethereal should be 2.5-5.5% faster on those traces.
anyone that wants to, please rerun GPROF with this fix and see what has changed.
svn path=/trunk/; revision=9058
memory if it throws an exception, as it checks whether the entire string
is in the tvbuff *before* allocating a buffer for it, and that also
means that if the length is absurdly large, an exception will be thrown,
rather than the memory allocation failing.
svn path=/trunk/; revision=9043
Make "proto_is_protocol_enabled()" and "proto_get_protocol_short_name()"
take a "protocol_t *" as an argument, so they don't have to look up the
"protocol_t" - this will probably speed them up considerably, and
they're called on almost every dissector handoff.
Get rid of a number of "proto_is_protocol_enabled()" calls that aren't
necessary (dissectors called through handles, including those called
through dissector tables, or called as heuristic dissectors, aren't even
called if their protocol isn't enabled).
Change some direct dissector calls to go through handles.
svn path=/trunk/; revision=8979
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
that probably means you've registered two fields with the same field ID
variable, which is an error.
Fix the bugs doing so found.
svn path=/trunk/; revision=8629
support for registering fields after all the protocol
registration routines are called (i.e., adding fields to the
named field tree as they're registered);
fix the GTK 2.x version of the field list dialog to show the
correct name.
svn path=/trunk/; revision=8248
use them when generating display filters to match field values. Use
"%{FLT_DIG}g" rather than "%{FLT_DIG}f" for FT_FLOAT.
svn path=/trunk/; revision=8109
have plugin support. (Don't do so if we *do* have it, because if
"proto_init()" ever changes so that it doesn't use the argument even if
we have plugin support, we want a warning so we know that we should get
rid of that argument.)
svn path=/trunk/; revision=7972
tvb_get_string() - takes a tvbuff, an offset, and a length as
arguments, allocates a buffer big enough to hold a string with
the specified number of bytes plus an added null terminator
(i.e., length+1), copies the specified number of bytes from the
tvbuff, at the specified offset, to that buffer and puts in a
null terminator, and returns a pointer to that buffer (or throws
an exception before allocating the buffer if that many bytes
aren't available in the tvbuff);
tvb_get_stringz() - takes a tvbuff, an offset, and a pointer to
a "gint" as arguments, gets the size of the null-terminated
string starting at the specified offset in the tvbuff (throwing
an exception if the null terminator isn't found), allocates a
buffer big enough to hold that string, copies the string to that
buffer, and returns a pointer to that buffer and stores the
length of the string (including the terminating null) in the
variable pointed to by the "gint" pointer.
Replace many pieces of code allocating a buffer and copying a string
with calls to "tvb_get_string()" (for one thing, "tvb_get_string()"
doesn't require you to remember that the argument to
"tvb_get_nstringz0()" is the size of the buffer into which you're
copying the string, which might be the length of the string to be copied
*plus 1*).
Don't use fixed-length buffers for null-terminated strings (even if the
code that generates those packets has a #define to limit the length of
the string). Use "tvb_get_stringz()", instead.
In some cases where a value is fetched but is only used to pass an
argument to a "proto_tree_add_XXX" routine, use "proto_tree_add_item()"
instead.
svn path=/trunk/; revision=7859
value, just copy the specified number of bytes and stick a '\0' at the
end, don't use "tvb_get_nstringz0()" - yes, you end up copying more
bytes, but you don't have to bother looking for a '\0' that might not
even be present (if the string is null-padded rather than
null-terminated).
Also, set the length of the item to the specified length, rather than to
the length up to the terminating '\0' - if the string is null-padded,
the field should include all the padding bytes.
svn path=/trunk/; revision=7785
length (rather than being given -1), the length is, in most cases, the
maximum length of a null-*padded* string, rather than the actual length
of a null-*terminated* string. Treat it as such - allocate a buffer one
larger than the length (to leave room for a terminating '\0'), and pass
the size of that buffer to "tvb_get_nstringz0()". (Otherwise, in those
cases, the last character of the string is chopped off.)
Allow "proto_tree_add_string()" to add FT_STRINGZ items to the protocol
tree, as well as FT_STRING items.
In "alloc_field_info()", if we're passed a length of -1 and the field is
an FT_STRINGZ, don't make the length be the length remaining in the
tvbuff; that way, you *can* use a length of -1 in
"proto_tree_add_item()" for an FT_STRINGZ item, and have it get the
actual length by looking for the terminating '\0'.
(We might want to distinguish between null-terminated and null-padded
strings, e.g. with an FT_STRINGZPAD type. Null-terminated strings
rarely, if ever, have a specified length; the length is found by
scanning for the terminating '\0'. Null-padded strings presumably
always have a specified length, which is the length to which the string
is padded.)
svn path=/trunk/; revision=7784
Things can happen if we pass a zero buffer length to tvb_get_nstringz0().
Throw an exception if this happens.
In various dissectors make sure the tvb_get_nstringz0()'s buffer length
is greater than zero.
svn path=/trunk/; revision=7688
"proto_construct_dfilter_string()", to more accurately reflect what it
does.
Give it, and "proto_can_match_selected()", an "epan_dissect_t *"
argument, which replaces the raw data pointer argument to
"proto_construct_dfilter_string()".
For fields that don't have a type we can directly filter on, we don't
support filtering on the field as raw data if:
the "epan_dissect_t *" argument is null;
the data source tvbuff for the field isn't the tvbuff for the
"epan_dissect_t" in question (i.e., it's in the result of a
reassembly, and "frame[N:M]" can't get at it).
Trim the length the raw data in the case of such a field to the length
of the tvbuff for the "epan_dissect_t" in question, so we don't go past
it. Fetch the raw data bytes to match from that tvbuff.
Have "proto_construct_dfilter_string()" return a null pointer if it
can't construct the filter string, and have "protocolinfo_packet()" in
the tap-protocolinfo tap ignore a field if
"proto_construct_dfilter_string()" can't construct a filter string for
it - and have it pass NULL as the "epan_dissect_t *", for now. If
somebody decides it makes sense to dump out a "frame[N:M] =" value for
non-registered fields, it can be changed to pass "edt".
svn path=/trunk/; revision=7635
given a tvbuff/offset pair referring to the byte past the end of the
item. Use it in one place in the SMB dissector (there are plenty of
other places where it could be used as well).
svn path=/trunk/; revision=7603
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
to be using it for stuff that should be hex, and for stuff that should
be Boolean. Use BASE_DEC if it should be decimal, BASE_HEX if it should
be hex, and make it Boolean if it should be Boolean.
svn path=/trunk/; revision=7053
"epan/proto.c" to properly handle string truncation (by checking both
for -1 and a value larger than the buffer size as an indication of
truncation, as some older versions of those routines return -1, and, if
the string was truncated, putting in a trailing '\0', as "snprintf()" on
some platforms might not put the trailing '\0' in).
svn path=/trunk/; revision=6830
frame number, which is always decimal. If you select an FT_FRAMENUM
field, there are menu items that let you go to the frame whose frame
number appears in that field.
Add FT_FRAMENUM fields for the ONC RPC "matching request is in this
frame" and "matching reply is in this frame" protocol tree items.
svn path=/trunk/; revision=6802
pointer, and put "const" into the casts in "VALS()" and "TFS()" macros,
so we don't un-constify pointers to "value_string" arrays and
"true_false_string" structures.
Make some things "const" to keep the compiler happy with the previous
change.
svn path=/trunk/; revision=6684
the same long name, short name, or filter name, and abort if there are.
Fix the duplicate names that found (and another name error found while
fixing one of those errors).
svn path=/trunk/; revision=6425
floating-point numbers, and display all the significant digits for both
single-precision and double-precision floating-point numbers in the
protocol tree, not just what "%g" does (6 digits).
Put in comments explaining how the length of filter strings is computed,
and fix some of the computations.
svn path=/trunk/; revision=6081
equivalents for the epan/ directory but leave winsock2.h in inet_pton.c
and inet_ntop.c for now (can't estimate the consequences).
svn path=/trunk/; revision=5928
the argument is "fields", dump out a table of the fields, as we
currently do; if the argument is "protocols", dump out a table of the
protocols.
svn path=/trunk/; revision=5462
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
move the code from "dfilter_lookup_token()" into
"proto_registrar_get_byname()", and get rid of "dfilter_lookup_token()"
and have its callers call "proto_registrar_get_byname()" instead.
svn path=/trunk/; revision=5287
Fix the display filter expression generated for protocol tree items
without named fields attached to them; the length defaults to 1 if not
specified in a range expression, so the length should be specified.
svn path=/trunk/; revision=5208
Ronnie Sahlberg