e now, but that way lies madness. And of course there are likely other
approaches I haven't considered yet.
So, what do you folks think should happen here? What approach would you
endorse?
Thanks in advance,
David Perry
[1]: https://gitlab.com/wireshark/wireshark/-/issues/17009
[2]: h
:06 -0500
From: David Perry
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Having/avoiding epan dependencies in wiretap
Message-ID: <02148f24-8ef1-8e54-68ac-90c996064...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
In brief, I've found some code
Sorry to drag up an old topic, but I've been thinking about this:
Message: 5
Date: Sat, 29 May 2021 09:32:29 +0200
From: Anders Broman
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Calling a dissector: Type for data
parameter
Message-ID:
Content-Type: t
Hello all! I'm writing to request fresh eyes, and possibly hands, on a
somewhat significant potential change to Wireshark.
There's an old bug, 14329, requesting support for multiple comments per
packet. I've got a proposed solution in merge request #2859: Instead of
creating new fields on wtap
that MR
for discussions about specific formatting details. This email is for the
general discussion of whether/how to apply and enforce formatting.)
Thanks for your time,
David Perry
he/him
[1]: https://gitlab.com/wireshark/wireshark/-/issues/17253
[2]: https://releases.llvm.org/13.0.1/tool
There are open issues for this already... sort of. #20431 reports that
tshark will linearly but unboundedly consume memory when run with the -M
option. #20432 is about CLI taps (not) freeing their memory properly,
and wondering what the best approach is to remedy it.
20432 asks a larger design
