Age | Commit message (Collapse) | Author | Files | Lines |
|
'i' has type 'bar' [-Wformat].
svn path=/trunk/; revision=50639
|
|
svn path=/trunk/; revision=50411
|
|
some circumstances. Use array_index as a variable name instead, to
avoid warnings.
svn path=/trunk/; revision=50404
|
|
whitespace.
svn path=/trunk/; revision=50401
|
|
svn path=/trunk/; revision=50400
|
|
From the comment above wmem_tree_insert32_array():
* If you use ...32_array() calls you MUST make sure that every single node
* you add to a specific tree always has a key of exactly the same number of
* keylen words or things will most likely crash. Or at least that every single
* item that sits behind the same top level node always have exactly the same
* number of words.
So clearly generating thousands of keys with random lengths while testing is
going to cause problems. Generate a set of random lengths, then use those
lengths consistently (but still generating random keys of those lengths).
Should hopefully fix the intermittent build-bot failures.
(unfortunately this does not manifest nicely, and I cannot see an easy way to
assert it so that we catch other people trying to use different-length key
subtrees)
svn path=/trunk/; revision=50184
|
|
svn path=/trunk/; revision=50182
|
|
svn path=/trunk/; revision=50181
|
|
tests, and add more details to that section.
Now we wait for the buildbots to fail again...
svn path=/trunk/; revision=50156
|
|
svn path=/trunk/; revision=50140
|
|
svn path=/trunk/; revision=50132
|
|
Put in a whole bunch of stderr output in the wmem tree tests in the hopes that
the next time one of the buildbots randomly (and irreproducibly) fails on this
step we'll have at least a bit of a hint as to where it happened.
svn path=/trunk/; revision=50131
|
|
Should help debugging https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8833
svn path=/trunk/; revision=50115
|
|
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8824
Convert bluetooth emem trees to wmem trees.
Add modelines and fix indentation.
Correct typo in wmem_tree.h that still referred to emem.
svn path=/trunk/; revision=50076
|
|
it is out of scope, they just can't *allocate* in the pool. This is necessary
because file-scope trees (migrating from emem) are set up on program
initialization when there is no file in scope - they need to initialize with the
handle, they just won't use it until a file is actually in scope.
svn path=/trunk/; revision=50046
|
|
svn path=/trunk/; revision=50039
|
|
unnecessary continue statements. Should fix the coverity issues Joerg pointed
out as well.
svn path=/trunk/; revision=50033
|
|
need to provide an analogue at least for now.
svn path=/trunk/; revision=50018
|
|
svn path=/trunk/; revision=50017
|
|
svn path=/trunk/; revision=50013
|
|
as well as a confusing while(TRUE).
svn path=/trunk/; revision=50012
|
|
enum for the color (red/black). Don't use bitfields since they don't save us
much (if anything) in terms of space and don't nest the fields in their own
anonymous struct.
svn path=/trunk/; revision=50011
|
|
svn path=/trunk/; revision=50010
|
|
svn path=/trunk/; revision=50009
|
|
use it for both direct lookups and less-than-or-equal-to lookups.
svn path=/trunk/; revision=50008
|
|
wmem_tree_new.
svn path=/trunk/; revision=50007
|
|
and lookup_string.
svn path=/trunk/; revision=50006
|
|
random seeds would cause collisions and false failures.
svn path=/trunk/; revision=50004
|
|
svn path=/trunk/; revision=50003
|
|
and enable the tests.
Lesson: make it work, *then* refactor it into sanity.
svn path=/trunk/; revision=50002
|
|
blow up. Not sure if the tests are wrong or if I broke something during the port
from wmem...
svn path=/trunk/; revision=49998
|
|
assertions with regular glib assertions - there's no guarantee that wmem code
will always be run from within a dissector.
svn path=/trunk/; revision=49993
|
|
svn path=/trunk/; revision=49971
|
|
svn path=/trunk/; revision=49970
|
|
it was originally registered.
svn path=/trunk/; revision=49969
|
|
svn path=/trunk/; revision=49968
|
|
trees.
svn path=/trunk/; revision=49966
|
|
if it's NULL, meaning we don't need to define an identity callback.
svn path=/trunk/; revision=49962
|
|
destruction order, and note that it may need thinking about.
svn path=/trunk/; revision=49952
|
|
(should it?)
svn path=/trunk/; revision=49951
|
|
version.
One plane trip's worth of work.
svn path=/trunk/; revision=49945
|
|
svn path=/trunk/; revision=49857
|
|
they're in doxygen instead.
svn path=/trunk/; revision=49583
|
|
actual wmem_allocator_t structure. This simplifies the internal API and
deduplicates a few alloc/free calls in the individual allocator implementations.
I'd originally made the allocators responsible for this on purpose with the
idea that they'd be able to optimize something clever based on the type of
allocator, but that's clearly more work and complexity than it's worth given
the small number of allocators we create/destroy.
svn path=/trunk/; revision=49512
|
|
svn path=/trunk/; revision=49444
|
|
for which a callback is registered is also a fairly stupid thing to do.
svn path=/trunk/; revision=49354
|
|
recurring callbacks, I suspect most other potential uses will be once-only, so
make that possible, and improve the documentation on the remaining issues.
Also separate out the code into its own files and the testing into its own
test case.
svn path=/trunk/; revision=49209
|
|
the behaviour emem has for seasonal trees, which is that the master tree
structure is not actually seasonal - it is permanent. When the seasonal memory
pool is cleared, the root node pointer in all of these permanent trees is set
to NULL, and the pool takes care of actually freeing the nodes.
Wmem can now mimic this by allocating the tree header struct in epan_scope(),
allocating any node structs in file_scope(), and registering a callback on
file_scope() that NULLs the pointer in the epan_scope() header. Yes, this is
confusing, but it seemed simpler than adding manual callback registrations to
every single dissector that currently uses seasonal trees.
The callbacks may also be useful for other things that need cleanup (I'm
thinking resource handles stored in wmem memory that need to be fclosed or
what-have-you before they the handle is lost).
As indicated by the number of caveats in README.wmem, the implementation
probably needs a bit of work to make it safer/saner/more-useful. Thoughts
(or patches!) in this direction are more than welcome.
svn path=/trunk/; revision=49205
|
|
compatibility with GLIB 2.14.
svn path=/trunk/; revision=49161
|
|
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8275
Implement wmem_slist_append().
svn path=/trunk/; revision=49094
|