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>
Gracefully handle repeated calls of ws_buffer_free on the same buffer to
avoid strange crashes in other new users that allocate a "small" buffer.
The first call to ws_buffer_free would store data pointer in the
'small_buffers' array for reuse and set the pointer to NULL. Result:
(gdb) p cfile.rec.options_buf
$2 = {
data = 0x0,
allocated = 2048, // Oops, not modified!
start = 0,
first_free = 0
}
All users of Buffer (including ws_buffer_free) however asssume that
'allocated' reflects the actual size of 'data'. If this is not the case
(if ws_buffer_free is called again), then a data pointer (NULL!) will be
stored and the next ws_buffer_init request for a "small buffer" will
result in unexpected behavior (including crashes).
Fix the issue by clearing the 'allocated' field as well. Add assertions
to catch such issues earlier rather than crashing at random users of
these buffers (such as frame_tvbuff).
Bug: 15263
Change-Id: I0b491c3fccac8c6fddd43779629343d721638ca9
Reviewed-on: https://code.wireshark.org/review/31278
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Id73e641499e75bc1afc1dea29682418156f461fe
Reviewed-on: https://code.wireshark.org/review/24751
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
The cleanup routine has been added to exit section of the applications.
Those which required a exit restyle have been patched as well.
Change-Id: I3a8787f0718ac7fef00dc58176869c7510fda7b1
Reviewed-on: https://code.wireshark.org/review/19949
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Try to minimize the number of times we allocate memory for Buffers and
Buffer data.
Change-Id: I738fdc64e571772ef4ba6335d49087277dd7b430
Reviewed-on: https://code.wireshark.org/review/16577
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Will look at cleaning up and committing script afterwards.
Change-Id: Id785e581740ab62fe9258ecfcb0926761ad9c527
Reviewed-on: https://code.wireshark.org/review/6086
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
In particular, epan/wslua/lrexlib.c has its own buffer_ routines,
causing some linker warnings on some platforms, as reported in bug
10332.
(Not to be backported to 1.12, as that would change the API and ABI of
libwsutil and libwiretap. We should also make the buffer_ routines in
epan/wslua/lrexlib.c static, which should also address this problem, but
the name change avoids other potential namespace collisions.)
Change-Id: I1d42c7d1778c7e4c019deb2608d476c52001ce28
Reviewed-on: https://code.wireshark.org/review/3351
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Otherwise, if you link with both libwiretap and libfiletap, it's
anybody's guess which one you get. That means you're wasting memory
with two copies of its routines if they're identical, and means
surprising behavior if they're not (which showed up when I was debugging
a double-free crash - fixing libwiretap's buffer_free() didn't fix the
problem, because Wireshark happened to be calling libfiletap' unfixed
buffer_free()).
There's nothing *tap-specific about Buffers, anyway, so it really
belongs in wsutil.
Change-Id: I91537e46917e91277981f8f3365a2c0873152870
Reviewed-on: https://code.wireshark.org/review/3066
Reviewed-by: Guy Harris <guy@alum.mit.edu>
João Valverde