Potentially all 3. In the example I looked at (packet-cmip.c), they were only used in one place each. In that case PFNAME is the string that prefixes all of the display filters, but it isn't used, so having/changing PFNAME is pretty pointless.
One design would have been to omit PFNAME from the filters, which would also ensure consistency, but I don't think that will change now. On Tue, Feb 3, 2026 at 10:08 AM Tamás Regős <[email protected]> wrote: > get rid of only PSNAME, or all three: PNAME/PSNAME/PFNAME ? > > On Tue, 3 Feb 2026 at 17:04, Martin Mathieson via Wireshark-dev < > [email protected]> wrote: > >> Hi Tamas, >> >> I'm not certain where the suggestion to use PSNAME is, the only reference >> I can quicily see is in./wsdg_src/wsdg_asn2wrs.adoc >> >> However, it has limited usefulness as we don't use it to fill in the >> first part of display filter names. I might prefer to get rid of it, but a >> discussion would need to be had before making that change. >> Martin >> >> On Tue, Feb 3, 2026 at 9:49 AM Tamás Regős <[email protected]> wrote: >> >>> Hi Martin, >>> >>> Literal vs PSNAME (and the other 2 as well) are pretty much mixed up and >>> I was often confused which way would be the better. >>> I think it could be perhaps an additional MR to fix all dissectors? I >>> know it would be quite an effort but then the code would be much more >>> straightforward. >>> >>> I used PNAME, PSNAME and PFNAME because I thought that would be the >>> right way. >>> >>> Since now it's mixed up, I fully agree with you to cover it the way you >>> said. I guess your proposal is simpler, faster and easier to implement than >>> eliminating all PNAME, PSNAME and PFNAME... >>> >>> Regards, >>> Tamas >>> >>> >>> On Tue, 3 Feb 2026 at 16:43, Martin Mathieson via Wireshark-dev < >>> [email protected]> wrote: >>> >>>> Hi Tamas, >>>> >>>> Most dissectors use literals instead of PSNAME, etc - which I think I >>>> prefer. >>>> >>>> However, we could try: >>>> - moving find_macros() from check_typed_item_calls.py to >>>> check_common.py and use that. It looks for simple #define and also matches >>>> (some) enums - has been used to get numerical values so far >>>> - have check_spelling.py also call that function, and attempt to >>>> substitute for the psname arg if it isn't a literal string? >>>> >>>> From epan/dissectors: >>>> grep proto_register_protocol *.c | grep PSNAME | wc -l >>>> 169 >>>> >>>> so I think it would be worth doing. I'm happy to look at this (or >>>> something simpler by only looking for PSNAME?), but it might be a few days >>>> before I get to it. >>>> >>>> Thanks again, >>>> Martin >>>> >>>> On Tue, Feb 3, 2026 at 8:48 AM Tamás Regős <[email protected]> wrote: >>>> >>>>> Hi Martin, >>>>> >>>>> "Words that appear as the name of a dissector/protocol should not be >>>>> reported (the script checks for proto_register_protocol() calls and adds >>>>> them to the dict)"... >>>>> I am not entirely sure it works that way. >>>>> >>>>> In my case: >>>>> >>>>> packet-qcdiag.c >>>>> #define PNAME "Qualcomm Diagnostic" >>>>> #define PSNAME "QCDIAG" >>>>> #define PFNAME "qcdiag" >>>>> ... >>>>> proto_qcdiag = proto_register_protocol(PNAME, PSNAME, PFNAME); >>>>> >>>>> example "Clang + Code Checks" (passed): >>>>> https://gitlab.com/infostam/wireshark/-/jobs/12947400694 >>>>> >>>>> epan/dissectors/packet-qcdiag.c 10 / 3922 "packet-qcdiag.c" qcdiag -> >>>>> ? >>>>> ... >>>>> epan/dissectors/packet-qcdiag.c 3902 / 3922 "qcdiag.ext_build_id.ver" >>>>> qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3904 / 3922 "qcdiag.ext_build_id.res" >>>>> qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3906 / 3922 "qcdiag.ext_build_id.msm" >>>>> qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3909 / 3922 >>>>> "qcdiag.ext_build_id.mob_model" qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3912 / 3922 >>>>> "qcdiag.ext_build_id.sw_rev" qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3914 / 3922 >>>>> "qcdiag.ext_build_id.mob_model_str" qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3915 / 3922 "qcdiag.cmd" qcdiag -> ? >>>>> epan/dissectors/packet-qcdiag.c 3916 / 3922 "QCDIAG Command" QCDIAG -> >>>>> ? >>>>> epan/dissectors/packet-qcdiag.c 3917 / 3922 "qcdiag.subsys_id" qcdiag >>>>> -> ? >>>>> epan/dissectors/packet-qcdiag.c 3918 / 3922 "QCDIAG Subsystem" QCDIAG >>>>> -> ? >>>>> >>>>> qcdiag : 43 >>>>> >>>>> If I add "qcdiag" to wireshark_words.txt, these lines disappear... >>>>> >>>>> What do you think? >>>>> >>>>> I will raise the MRs. >>>>> >>>>> Regards, >>>>> Tamas >>>>> >>>>> On Tue, 3 Feb 2026 at 15:37, Martin Mathieson via Wireshark-dev < >>>>> [email protected]> wrote: >>>>> >>>>>> Yes, of course. A quick check for where 'len(word)' appears in >>>>>> tools/check_spelling.py - I think words < 5 characters won't be reported >>>>>> anyway, so some of the ones you mention would be too short. >>>>>> >>>>>> Words that appear as the name of a dissector/protocol should not be >>>>>> reported (the script checks for proto_register_protocol() calls and adds >>>>>> them to the dict), although the order that files are checked can >>>>>> obviously >>>>>> affect whether or not they have already been loaded. >>>>>> >>>>>> I see your other email about tools/check_spelling.py next - I was a >>>>>> little hasty in making these checking tools use concurrent.futures - the >>>>>> speedup is amazing though :) >>>>>> Your help in fixing this would be much appreciated. >>>>>> >>>>>> Martin >>>>>> >>>>>> On Tue, Feb 3, 2026 at 7:57 AM Tamás Regős <[email protected]> wrote: >>>>>> >>>>>>> Hi Dev Team, >>>>>>> >>>>>>> Is it OK to submit an MR for updating tools/wireshark_words.txt file >>>>>>> with some words? >>>>>>> >>>>>>> For example: gsm, gsmtap, lte, nr, rrc, umts, wcdma? >>>>>>> >>>>>>> Regards, >>>>>>> Tamas >>>>>>> _______________________________________________ >>>>>>> Wireshark-dev mailing list -- [email protected] >>>>>>> To unsubscribe send an email to [email protected] >>>>>>> >>>>>> _______________________________________________ >>>>>> Wireshark-dev mailing list -- [email protected] >>>>>> To unsubscribe send an email to [email protected] >>>>>> >>>>> _______________________________________________ >>>>> Wireshark-dev mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> _______________________________________________ >>>> Wireshark-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >>> Wireshark-dev mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> Wireshark-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Wireshark-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
