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]
