Re: So why is _ws.expert an FT_PROTOCOL field rather than an FT_STRING field?

[Guy Harris <guy () alum mit edu>]

On Apr 12, 2016, at 7:01 PM, Michael Mann <mmann78 () netscape net> wrote:

> Because it made sense to integrate the expert info under the protocol architecture (and register it through 
> proto_register_protocol("Expert Info", "Expert", "_ws.expert"); ).  The "string version" of the field would be 
> "_ws.expert.message"

No, the "string version" of "_ws.expert" wouldn't be another field, it would be the string displayed for _ws.expert in 
the protocol tree.  In bug 12335, they're *NOT* looking at _ws.expert.message to see whether it contains a particular 
string, they're looking at _ws.expert to see whether it contains a particular string.

Either we have to somehow *forbid* the use of _ws.expert in filter expressions - *without* forbidding the use of other 
FT_PROTOCOL fields! - or we need to make it work without crashing.

If we decide to make it work without crashing, the "string version" of _ws.expert would be the

        Expert Info ({severity}/{group}): {message}

text, and I suggest that we:

        1) rename ftype-tvbuff.c to ftype-protocol.c, so as not to suggest that this is a "this is a tvbuff" value type 
(its FT_ value is FT_PROTOCOL, not FT_TVBUFF);

        2) change all the functions in there *not* to assume that there's a non-null tvb value and to, if the tvb value 
is null, treat the formatted string value as the value to compare/match/check-for-contains/etc.;

because that's what we'd have to do in order to fix this problem.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe