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]
