https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16232

--- Comment #6 from Peter Wu <pe...@lekensteyn.nl> ---
(In reply to Jaap Keuter from comment #2)
> So, we're going to learn this C code all kinds of polymorphism tricks and

Yes, it sucks to be C ;)

> safety features, while expecting it to be as efficient (both in programmer
> time as in execution) as the generic solution currently applied. If we're
> purely talking about interfacing between C and Lua, than please say so.

Not just C and Lua, also C to C. commit 83220acb48 is an example of what can go
wrong. Perhaps I was misusing the API, but when I checked the
doc/README.dissector docs yesterday, I could not see a description of the
'data' parameter.

The proposed solution adds one extra memory indirection and a tiny bit of stack
cost, but provides more safety and opens the door for easier interfacing with
Lua. Programmer time (after a one-time conversion) should be saved by less risk
of misuse :)

I currently believe that some form of type tagging is necessary. If not
implemented by changing the 'void *' type, then it could be passed through a
pinfo field. This is not very explicit and there is an increased risk of
programming errors.

(In reply to João Valverde from comment #3)
> I don't think dissectors should be passing values at all.

That is something that I would like to figure out by studying existing
dissectors using automated tooling. I do know that some dissectors expose
dissector-specific routines because there is no standard way to share data
between dissectors (think of getting TLS state information into QUIC). Maybe it
could become a bit more standardized, or maybe the status quo should be kept.
With more data I hope it is easier to make a better decision.

> Furthermore the values in the proto tree are inherently type safe (ftypes).

I considered reuse of ftypes instead of a new type system, but ftypes seem to
have significant overhead (memory allocations) and is not suitable for opaque
types (pointers to C structures). As you mentioned, querying existing proto
items is not cheap either, but it can also fail to be useful if multiple items
exist. It also does not work if the tree is NULL.

Thanks for your feedback!

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to