tvbuff.c:1258: warning: passing argument 2 of '__builtin___memcpy_chk' makes pointer from integer without a cast
tvbuff.c:1258: warning: passing argument 2 of '__inline_memcpy_chk' makes pointer from integer without a cast
svn path=/trunk/; revision=53117
proto_tree_add_item was valid *before* we short-circuited based on a NULL tree.
This was good in that it removed a common source of really-long-loop bugs. It
was less good in that it cost us about 8% in speed when doing a tree-less
dissection, but we decided the tradeoff was worth it.
After Anders' recent mail to -dev about performance, I started thinking about
how to optimize this. It occurred to me that the vast majority of the logic
involved in the check was dealing with the length value - fetching the actual
length if it was a counted string, calculating the length if it was -1, adding
the length to the offset in a way that was free from overflows, etc.
All of this is (theoretically) unnecessary - simply checking the offset without
worrying about the length will still catch the very-long-loops, since it is the
offset that increases in each iteration, not the length.
All that to justify:
- implement tvb_ensure_offset_exists which throws an exception if the offset is
not within the tvb
- use it instead of all the complicated other logic in the pre-short-circuit
step of proto_tree_add_item and friends
This gives us back about 3/4 of the performance we lost in the original patch.
We're still ~2% slower than without any check, but this is the best I can think
of right now.
svn path=/trunk/; revision=52578
dissecting without tree, they are costly because they now happen for every
proto_tree_add_item call even if tree is NULL.
svn path=/trunk/; revision=52575
explicit, and frees up the "generic" names (like tvb_memdup) for new signatures
that take the appropriate wmem pool.
Majority of the conversion done with sed.
svn path=/trunk/; revision=52164
- support merging chains in tvb_add_to_chain
- when we have an old reassembled TVB, just merge the chains rather than
freeing it (we may still need it as it may already be a data source)
- modelines
Fixes https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9027
#BACKPORT, but it's gonna be messy...
svn path=/trunk/; revision=51825
We either want to calculate only offset (compute_offset()), or
offset and remaining length (compute_offset_and_remaining())
Move old generic code to check_offset_length_no_exception())
svn path=/trunk/; revision=50551
+ if there's overflow in check_offset_length_no_exception() just set exception, don't clamp end_offset (it could be an issue for 4GB tvbs :>)
svn path=/trunk/; revision=50549
Right now it doesn't really matter, cause tvb subsets always have real_data.
Without fix, and with small modification in ensure_contigous_no_expcetion() to first check for ->tvb_get_ptr() and later real_data
epan doesn't work and it flood console with warnings like:
** (process): WARNING **: Dissector bug, protocol IPv4, in packet 3823: tvbuff.c:976: failed assertion "exception > 0"
svn path=/trunk/; revision=50537
->tvb_init() knows nothing about new tvb and can only do some kind of bzero()
it's much better if we initialize object after tvb_new() [which anyway must be done]
+ try to fix OSX build.
svn path=/trunk/; revision=50490
Note: There are other ways to handle this of course, but this fix is suitable for backporting to both 1.10 and 1.8, as it does not break binary compatibility. Is there a better way to fix this though? For now, schedule this for backport.
svn path=/trunk/; revision=50282
which we're making a subset, so that if the parent tvbuff is marked as a
fragment, the child tvbuff will be marked as one as well.
svn path=/trunk/; revision=48953
