Wireshark-bugs: [Wireshark-bugs] [Bug 8961] Enhancement: Add dissector for the STANAG 4607 GMTIF
Comment # 12
on bug 8961
from Evan Huus
(In reply to comment #10)
> OK, I'll look.
>
> FYI,
> grep THROW epan/dissectors/* |grep ReportedBound |wc
> 358
>
> so I assumed that was the appropriate solution.
Throwing is sometimes the right thing to do, but not in this case. I also
suspect that some of those are simply wrong - with the number of dissectors we
maintain, API changes don't always fully propagate.
(In reply to comment #11)
> ... Is there a "best practices" dissector that can be used as an example?
> README's can only go so far; often its easiest to just look at how everyone
> else is doing it, and emulate that (which is what I did ... I picked some
> dissector, forget which, and copied the indentation style, the license
> boilerplate, the line-break style for hf_register_info, the naming
> conventions, etc. Its also how I spotted the THROW ...
The file doc/packet-PROTOABBREV.c is intended to be the starting boilerplate
for new dissectors. It doesn't cover every case (in particular, it doesn't have
any expert info in it) but it is well-commented and worth reading.
Otherwise, most protocols are hit and miss. Popular ones like TCP are
well-kept, but too complicated to be reasonably understood (both because the
protocol is complex and because the dissector implements a lot of extra
features). The bluetooth family (packet-bt*.c) has received a lot of
maintenance recently, so is probably a decent place to look.
In general, if you're not sure what the best way to handle a case is, the
safest answer is just to ask, we're happy to help. Suggestions on improving the
documentation are always welcome, as well: as I noted, it's easy to lose the
necessary perspective when you become too familiar with how things work.
You are receiving this mail because:
- You are watching all bug changes.
