(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Depends on I1cedc611c9b7888eb671cf858c6f7819d37afba9
Change-Id: I5dda2f7c34eacb6f350473791df1d74ea4b4a749
Reviewed-on: https://code.wireshark.org/review/220
Reviewed-by: Michael Mann <mmann78@netscape.net>
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
from one case I consistently forgot when typing it up originally, even though
it's clearly listed several places in my design notes.
Also include an #if0-ed out block of code to redirect emem to wmem for easy
testing (since there are very few common dissectors that use wmem right now).
svn path=/trunk/; revision=48434
glib memory slices.
- We weren't doing anything with the emem slab that couldn't be done with glib
slices.
- Removes a fair bit of code as well as one debugging environment variable.
- Glib slices are much cache-friendlier and are multi-threading friendly (if
we ever go there).
- Allows glib to actually return slices to the OS on occasion. The emem slab
would hold onto its memory forever which resulted in a great deal of wasted
memory after closing a large file.
svn path=/trunk/; revision=48218
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
Alexis La Goutte