variable (WIRESHARK_DEBUG_USE_SLICES) which turns off the slab allocator and uses
g_slices instead (which can themselves be turned off by setting
G_SLICE=always-malloc).
This makes debugging problems in slab-allocated memory easier to find
(hopefully including https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8197 ).
Set WIRESHARK_DEBUG_USE_SLICES when running Valgrind on *shark.
Remove unused structure member: emem_chunk_t.org.
svn path=/trunk/; revision=47110
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
used for - it represents a memory pool that parcels out memory from
larger allocated chunks (reducing the number of individual malloc-style
calls that are made) and that can be freed in its entirety.
svn path=/trunk/; revision=45400
packet-classicstun.c
packet-reload-framing.c (probably)
packet-reload.c
packet-sccp.c
packet-sua.c
packet-tcp.c
packet-xmcp.c
\epan\gcp.c
The following files unnecessarily recreate keys because of the previously destructive nature of emem_tree_*32_array functions:
packet-btl2cap.c
packet-nfs.c
packet-rpc.c
packet-scsi-osd.c
packet-stun.c (per Bug 7569)
These could be cleaned up, but it's not like the key recreation is burning CPU cycles.
svn path=/trunk/; revision=44380
(emem alignment problems on SPARC) :
Have emem use 8-byte alignment when we need it.
Since I can't seem to write code that which reliably (across GCC versions and
optimization levels) determines if 8-byte alignment is needed for doubles,
"when" is defined as "if we're compiling for a CPU other than i386."
Windows doesn't need a check because it's either i386 or 64-bit (x86_64 or
maybe ia64--both of which get 8-byte alignment from G_MEM_ALIGN).
(And, yes, all of this is ignoring the 16-byte alignment requirements of long
doubles.)
svn path=/trunk/; revision=42431
(emem alignment problems on SPARC) :
Add the room for the pointer to the next (from r31577) *before* calculating
the canary+pad: that way the complete allocation
(allocation+canary_ptr+canary+pad) will end on an 8-byte boundary (as was the
case before r31577).
This only solves the alignment problem when using canaries (i.e., not, by
default, se_ allocations).
(And, yes, this is ignoring the 16-byte alignment requirements of long
doubles.)
svn path=/trunk/; revision=42407
prevents OutOfMemory exceptions from being thrown. This makes it easier
to debug such conditions.
Set this variable in test-fuzzed-cap.sh but not in fuzz-test.sh; it's nice
to see the friendly out-of-memory error message in the bug reports the
latter script generates.
svn path=/trunk/; revision=41656
isn't. If it is, we don't need to worry about alignment, so the XXX
comment doesn't belong there; if it isn't, then we should do what the
comment says. For now, assume the comment before the XXX comment is
correct, and just cast away the alignment warning.
svn path=/trunk/; revision=36795
In convert_string_case() use g_utf8_strup() instead of converting each
character by hand. Hopefully this won't cause any unexpected changes in
behavior.
svn path=/trunk/; revision=36006
truncates newly created and copied strings. The problem was that
strlen() (which returns a length not counting the NULL terminator) was
being mixed with functions that do malloc() (which need to allocate
memory large enough to inculde the NULL string terminator).
svn path=/trunk/; revision=35128
WIRESHARK_SE_VERIFY_POINTERS that control whether or not we verify if a given
pointer is ep_ or se_ allocated, respectively.
Turn the behavior off by default for speed reasons (the speed difference isn't
huge, but...).
Turn the behavior on when fuzz testing.
Document these two new variables in the man pages.
svn path=/trunk/; revision=34046
Added se_tree_lookup32_array_le to emem.[ch]. This function is similar to
se_tree_lookup32_le already defined.
Updated README.binarytrees to reflect this added function and corrected minor
spelling issues.
svn path=/trunk/; revision=31812
"g_strlcpy() assumes that src *IS* ASCII NUL terminated. If the src buffer is
not NUL terminated, g_strlcpy() *WILL* read past the end of the buffer."
svn path=/trunk/; revision=31782
Jeff Morriss