Change all wireshark.org URLs to use https.
Fix some broken links while we're at it.
Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c
Reviewed-on: https://code.wireshark.org/review/34089
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Yes, the rename of structure members is a bit hacky.
Yes, catering to Windows since "GLib's v*printf routines are
surprisingly slow on Windows".
But it does pass checkAPIs.pl
Change-Id: I5b1552472c83aa2e159f17b5b7eb70b37d03eff9
Reviewed-on: https://code.wireshark.org/review/15404
Reviewed-by: Michael Mann <mmann78@netscape.net>
Rather than using a hash table, which is overkill and slow, embed a
doubly-linked-list in the prefix structure.
On my tests with some random capture file and tshark -nxVr:
- normal block allocator: ~2.1 seconds
- old (slow) strict allocator: ~4.2 seconds
- new (fast) strict allocator: ~2.8 seconds
The buildbot will thank me :)
Change-Id: I2fb42229c4ee4c40bbe45ba04b7848792998eaa9
Reviewed-on: https://code.wireshark.org/review/1251
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(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>
a NULL allocator. This gives us a single, central place to handle out-of-memory
errors (by, for example, throwing an exception) for basically all of epan.
The only remaining glib memory that is directly allocated is for the hash tables
used by the simple and strict allocators.
svn path=/trunk/; revision=51627
makes canary checking about 20% faster, which should speed up fuzz-testing now
that more and more dissectors use wmem.
svn path=/trunk/; revision=51620
header later causes it to be redefined - as happens on my Solaris 11
virtual machine - we get a redefinition warning, which gets treated as
an error.
svn path=/trunk/; revision=51344
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
João Valverde