[Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>]

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 <regost@xxxxxxxxx> 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 <wireshark-dev@xxxxxxxxxxxxx> 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 <regost@xxxxxxxxx> 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 <wireshark-dev@xxxxxxxxxxxxx> 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 <regost@xxxxxxxxx> 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 <wireshark-dev@xxxxxxxxxxxxx> 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 <regost@xxxxxxxxx> 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 -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx