ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 52341: /trunk/epan/ /trunk/epan/diss

Date: Fri, 4 Oct 2013 10:12:08 -0400 (EDT)
I like the suggestion of a "_ws." prefix, but my hesitation is backwards compatibility.  The only "not real" protocol filter I use consistently is "malformed" and I like that simplicity.  And the other "protocols" in show_exception.c seem reasonable, but like you said, it starts to get ugly for some of the "lesser" error cases. 
 
Should I provide a patch here with your suggestion or log something in Bugzilla for people to test?
-----Original Message-----
From: Joerg Mayer <jmayer@xxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Oct 4, 2013 8:55 am
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 52341: /trunk/epan/ /trunk/epan/dissectors/: packet-usb-video.c /trunk/epan/: expert.h proto.c proto.h

On Thu, Oct 03, 2013 at 01:54:03AM +0000, mmann@xxxxxxxxxxxxx wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52341

>  Make expert items used in "low level" proto functions filterable (and ensure 
they are called even with a NULL tree).  I don't really like the Type Length 
Mismatch "protocol", but it doesn't seem that much different than the exception 
"protocols".

Ah yes, this is UGLY. Is there a way we can Prefix all non-protocol filters
like columns and expert items with something like "_ws." or "WS." thus
indicating that these are not "real" protocol filters?
And maybe all expert stuff should be prefixed "_ws.expert."

Ciao
      Jörg
-- 
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe