On Sun, Nov 25, 2001 at 01:04:21AM -0500, Ed Warnicke wrote:
> Is the CHECK_DISPLAY_AS_DATA macro still necessary?
It's currently used in:
"dissect_fr_uncompressed()", which is called from the Wellfleet
Compression Protocol dissector - which could be called via a
dissector handle (and probably should be called through it);
"dissect_atmarp()", which is called from the ARP dissector if
the hardware type of the ARP packet is ARPHRD_ATM2225 - this
could also be called through a handle;
"dissect_arp()", which is only called through a dissector table;
"dissect_ipp()", which is called through the HTTP dissector's
port-based dissector table;
"dissect_quake()", which is called as a conversation dissector -
and, as the comment in it notes, conversation dissectors
currently do *not* have protocols associated with them, so the
is-protocol-enabled? check is *not* done for them;
"dissect_rtcp()", which is also called as a conversation
dissector;
"dissect_snmp()", which is also called as a conversation
dissector;
"dissect_tftp()", which is also called as a conversation
dissector;
"dissect_quake2()", which is also called as a conversation
dissector;
"dissect_quakeworld()", which is also called as a conversation
dissector;
"dissect_ieee80211_mgt()", which is called internally from the
802.11 dissector *and is handed an extra argument* (the frame
control field), so it's not of type "dissect_t";
"dissect_rtp()", which is also called as a conversation
dissector.
So, right now, yes, it's still necessary.
If the conversation-dissector code were changed so that a dissector
handle, rather than a pointer to the dissector function, were handed to
"conversation_set_dissector()" as an argument, many of the calls to
"CHECK_DISPLAY_AS_DATA()" could be eliminated; some others could
probably be eliminated with no other code changes, and others could
probably be eliminated if calls were made through a handle.
"dissect_ieee80211_mgt()" would take some more work, though.
