Wireshark-dev: Re: [Wireshark-dev] RRC filters

From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Tue, 25 Sep 2012 16:58:54 +0200
2012/9/25 Anders Broman <anders.broman@xxxxxxxxxxxx>
 


From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Pascal Quantin
Sent: den 25 september 2012 16:35
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] RRC filters

Hi Lucio,

2012/9/25 Lucio Di Giovannantonio <lucio.digiovannantonio@xxxxxxxxx>
Hello to everybody, I've found something strange in rrc filters _expression_, in several cases the same filter abbreviation have different type, this can be a problem and/or can cause a crash?

for example:

{ &hf_rrc_criticalExtensions_117,
      { "criticalExtensions", "rrc.criticalExtensions",
        FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_117_vals), 0,
        "T_criticalExtensions_117", HFILL }},

and

{ &hf_rrc_criticalExtensions_118,
      { "criticalExtensions", "rrc.criticalExtensions",
        FT_NONE, BASE_NONE, NULL, 0,
        "T_criticalExtensions_118", HFILL }},

This is a side effect of the code auto generated from the ASN.1 description. I proposed a workaround in bug 2402 comment #14.
With it, the filters become:
{ &hf_rrc_criticalExtensions_117,
      { "criticalExtensions", "rrc.criticalExtensions",
        FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_117_vals), 0,
        "T_criticalExtensions_117", HFILL }},

and

{ &hf_rrc_criticalExtensions_118,
      { "criticalExtensions", "rrc.criticalExtensions_label",
        FT_NONE, BASE_NONE, NULL, 0,
        "T_criticalExtensions_118", HFILL }},

But I'm not really satisfied with the _label extension and could not come up to a better wording, so did not commit it. Any comment / suggestion is welcome :)

Regards,
Pascal.
 
Is this due to "duplicated field" names? If so one could try to rename them, but as I remember there is lots...

Yes this is due to the duplicated field names. Renaming all of them is a nightmare... That's why my patch was addressing the worst case (FT_NONE vs everything else). It will not cover all cases for sure, but it was a bit better than nothing...